Если вам приходилось руководить разработкой программного продукта, вы наверняка задумывались — как помочь команде двигаться быстрее? И как вообще понять, насколько быстро вы движетесь?

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

Раз мы можем успешно применять метрики к самим программным продуктам, почему бы не применить их к скорости разработки этих продуктов? Мы могли бы в таком случае пробовать какие-то улучшения в процессах и наглядно видеть, помогают ли они двигаться быстрее. Да и проблема определения справедливой зарплаты для программистов тоже бы упростилась. Какие метрики можно было бы использовать?

У нас нет хороших метрик для этого

Скорость разработки — это выполненный объем работы в единицу времени. Время мы можем измерить, тут все просто. А вот как измерить выполненный объем работы? Попытки сделать это начались много десятилетий назад, вместе с зарождением самой индустрии программирования. Однако каждый раз, когда показатель начинали использовать как цель для улучшения, обязательно что-то шло не так. Например:

• Количество строк кода. Это, наверное, старейшая метрика, которую уже окончательно никто не воспринимает всерьез. Если так оценивается объем работы, это приводит к замусориванию избыточным кодом, а разработчики начинают предпочитать самые простые задачи, избегая сложных проблем;
• Количество коммитов. Разработчики будут стараться дробить свои коммиты на более мелкие и, опять же, избегать сложных проблем;
• Количество выполненных задач. Стимулирует дробить задачи на более мелкие. Каждая проблема, даже незначительная, будет оформлена в виде задачи. Помимо этого, создает стимул срезать углы, если это приводит к скорейшему закрытию задач;
• Количество багов или процент багов. Метрика не объема, но качества работы. Если поставить ее как цель, разработчики будут бояться вносить изменения, а также будут неохотно рапортовать об ошибках, которые они нашли сами;
• Оценка задач в часах или сторипойнтах. Если продуктивность команды измеряется в единицах, которые она сама же и оценивает, нетрудно догадаться, к чему это приведет — со временем, оценки начнут завышаться;
• … и так далее.

Разработчики сообразительны и креативны, и они специализируются на решении сложных задач. Какую бы метрику вы им ни дали, они найдут самый простой способ улучшить показатели, но, скорее всего, он не будет иметь ничего общего с реальным объемом и качеством выполняемой работы. Будут ли они использовать эти “читерские” способы? Необязательно, это зависит от конкретной ситуации, в том числе от того, насколько сильный стимул вы создадите. Но они совершенно точно будут осознавать, что оценка их продуктивности слабо связана с принесением пользы. Это не только демотивирует, но и отвлекает от выполнения реальной работы.

Но почему?

Почему для улучшения свойств программных продуктов метрики прекрасно работают, но для измерения выполненной программистами работы — нет? Может, это какой-то заговор программистов? На самом деле, если мы посмотрим за пределы разработки ПО, то увидим и другие примеры, в одних из которых метрики работают хорошо, а в других — нет.

Примеры, когда метрики хорошо работают — массовое промышленное производство или продажи. Пусть будет производство и продажа кружек. Вы можете измерять объем производимой продукции — количество кружек в единицу времени, ее качество (процент брака), себестоимость одной кружки. В продажах — объем продаж, наценку. Эти метрики вполне успешно используются в управлении. Например, начальнику производства можно поставить задачу снижения процента брака при сохранении себестоимости, а начальнику отдела продаж — увеличения объема продаж при сохранении цены. Улучшения этих показателей принесут пользу бизнесу, так что их можно считать и показателями эффективности труда людей, которые за это отвечают.

Пример когда метрики не работают — оценка научной деятельности. Ученые производят исследования, которые потом публикуются в виде научных работ. В этой области тоже есть свои численные метрики — количество работ, количество цитирований, статистическая значимость результатов и др. Можно ли сказать, что ученый, выпустивший 10 научных работ, принес миру в два раза больше пользы, чем ученый, выпустивший 5 работ? Вряд ли, потому что ценность их трудов может сильно отличаться, и при этом даже на субъективном уровне бывает сложно понять, какой труд был более ценным. Проблема “накрутки” цитирований и публикаций широко известна в научной среде, так что, к сожалению, они не считаются надежными показателями ценности. Есть также и проблема манипуляций со статистической значимостью.

Два главных критерия

Вне зависимости от контекста у хорошо работающих метрик есть две общие черты:

1. Прямая (а не косвенная) связь с ценностью;
2. Точность, то есть метрика основана на измерении количества каких-то единиц ценности и эти единицы равны между собой;

Давайте посмотрим еще раз на примеры, которые мы рассматривали выше:

Метрики для массового производства и продаж удовлетворяют обоим критериям. В производстве кружек ценностью выступает продукция — сами кружки. Связь прямая, предприятию как раз и нужно производить кружки. А раз производство массовое, то единицы ценности (кружки) равны между собой. Если же мы говорим о продажах, то единицами ценности становятся деньги. Целью деятельности предприятия является получение прибыли, поэтому связь с ценностью, опять же, прямая. А поскольку каждый вырученный доллар равен другому, мы можем строить точные метрики.

В оценке научных трудов эти критерии соблюсти не удается. Мы не можем найти единицу измерения, которая бы напрямую определяла ценность научного труда, потому что все научные труды уникальны. По-другому быть и не может, просто исходя из самой сути науки — открывать новые знания. Ученому нет никакого смысла писать еще один научный труд, который бы в точности повторял другой. Каждая научная работа должна нести что-то новое.

Поскольку метрик, напрямую измеряющих ценность научного труда, мы найти не можем, то нам остаются только косвенные — например, количество публикаций и цитирований. Проблема с косвенными метриками в том, что они плохо коррелируют с ценностью и, как правило, легко подвержены “читерству”. Если вы начинаете использовать такую метрику в качестве цели, то вы сами создаете стимул ее искусственно накручивать.

Вернемся к измерению производительности программистов

Что у нас там было? Строчки кода, количество коммитов, задач, оценка задач в часах или сторипойнтах… Если вы попробуете проверить эти метрики на соответствие двум главным критериям, вы увидите, что ни одна из них им не соответствует:

1. Нет прямой связи с ценностью. Мы не поставляем нашим клиентам строчки кода, человеко-часы или сторипойнты. Пользователям нет никакого дела, сколько коммитов мы сделали или сколько задач закрыли;
2. Они не являются точными. Коммит коммиту рознь, одна строчка кода не равноценна другой, задачи тоже разные, а человеко-часы и сторипойнты оценены субъективно, поэтому также будут отличаться.

Так что нет ничего удивительного, что ни одна из этих метрик не работает — они же все косвенные и неточные.

А почему нет метрик, которые были бы напрямую связаны с ценностью труда программиста? По тем же причинам, почему их нет и у ученых. Программисты, как и ученые, постоянно создают что-то новое. Они не пишут в точности один и тот же код повторно — в этом нет смысла. Ранее написанный код можно переиспользовать разными способами, выделить его в отдельный модуль или библиотеку, ну, или просто скопировать, на худой конец. Поэтому каждый рабочий день у программистов уникален. Даже если они и решают похожие задачи, они решают их каждый раз в разном контексте, в новых условиях.

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

А нет ли чего-то более современного, основанного на исследованиях?

Конечно, сегодня уже никто всерьез не говорит об измерении труда программиста строчками кода. Должны же быть какие-то более современные метрики, основанные на исследованиях, верно?

Есть и такие. В книге 2018-го года “Accelerate” авторы приводят результаты исследования 2000 организаций из разных отраслей. Авторы пытались выяснить, какими метриками можно было бы оценивать эффективность:


Источник: Nicole Forsgren, Jez Humble, and Gene Kim, “Measuring Performance,” in Accelerate: The Science behind DevOps: Building and Scaling High Performing Technology Organizations

Здесь приведены четыре метрики. Давайте посмотрим, какие из них связаны с ценностью и могут быть точно измерены:

• Частота поставок в продакшен. Я понимаю, почему эту метрику привели здесь. Чем чаще вы поставляете код в продакшен, тем лучше отлажен процесс поставки. Более продуктивные команды обычно поставляют код чаще. Однако корреляция не означает причинности. Вряд ли это напрямую связано с ценностью для клиента. Людям нужно, чтобы продукт решал их задачи, а не чтобы он как можно чаще менялся. Метрика также не является точной, потому что поставка поставке рознь. В одной поставке могли быть сделаны серьезные изменения, в другой — тривиальные;
• Lead time — время, в течение которого удовлетворяется запрос клиента. Эта метрика лучше связана с ценностью для клиента, поскольку мы говорим об изменениях в продукте, о которых он сам просил. Она не является при этом точной, потому что, опять же, изменения изменениям рознь — сложность их реализации может отличаться на порядки;
• Время восстановления после сбоя (MTTR) — если ваша программа не работает, клиенты грустят, так что связь с ценностью присутствует, и это хорошо. Но есть и недостатки. Во-первых, метрика не учитывает частоту сбоев. Частые сбои с быстрыми восстановлениями тоже будут расстраивать ваших клиентов, но MTTR этого не покажет. Во-вторых, она является неточной, ибо сбои бывают разные. Некоторые очень серьезные, другие — нет;
• Процент изменений, в процессе внесения которых возникали сбои. Связь с ценностью имеется в основном в ситуациях, когда пользователи устанавливают обновления самостоятельно. Если, согласно прошлому опыту, обновления несут существенный риск, люди будут бояться их устанавливать. Как говорят пользователи некоторых дистрибутивов Linux, “не было печали — апдейтов накачали”. В случае SaaS-продуктов связь с ценностью более слабая. Пользователям неважно, по какой причине у вас возник сбой — из-за изменений, сбоя у вашего провайдера, высокой нагрузки или чего-то еще. Им важно, чтобы ваш сервис всегда работал. Как и другие метрики выше, эта тоже не является точной по той же самой причине — изменения изменениям рознь. Одни серьезные, другие — нет.

Итого: ни одна из этих четырех метрик не является точной, и не всегда у них прослеживается четкая связь с ценностью для клиента. Есть ли в этом случае возможность для “читерства”? Конечно. Поставляйте тривиальные малорисковые изменения как можно чаще, и все метрики, кроме Lead time, будут выглядеть прекрасно.

Что касается Lead time — даже если опустить тот (немаловажный) факт, что она неточная, упор на нее приведет к приоритезации самых простых хотелок клиента и задвиганию в дальний угол всего, о чем клиент явно не просил — обычно это рефакторинги, тесты, да и просто любые улучшения, о которых он сам не подумал.

Поэтому я бы не рекомендовал использовать эти метрики в качестве целей.

Но может, мы найдем новые метрики?

Вы, конечно, можете сказать: “Подождите, если годных метрик пока еще не найдено, это же не значит, что их вообще быть не может! Мы люди умные, поднапряжемся и что-нибудь придумаем”. Увы, боюсь, не выйдет. Существует фундаментальная причина, почему в этой области нет хороших метрик. Как мы уже говорили выше, хорошие отвечали бы двум главным критериям:

1. Прямая (а не косвенная) связь с ценностью;
2. Точность, то есть метрика основана на измерении количества каких-то единиц ценности, и эти единицы равны между собой.

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

Можно ли улучшить области, для которых нет хороших метрик?

Метрики очень удобны, потому что предоставляют обратную связь. Вы делаете какие-то изменения в процессе и можете наглядно видеть, привели они к улучшениям или нет. Если же метрик нет, то обратная связь становится не такой явной и может даже создаваться ощущение, что вы двигаетесь вслепую. Есть известное высказывание, приписываемое Питеру Друкеру:

Вы не можете управлять тем, что не можете измерить.

Только это неправда. Согласно Институту Друкера, Питер Друкер на самом деле не питал иллюзий, что для любой деятельности можно найти метрику, и никогда не говорил таких слов. Не все, что ценно, можно измерить, и не все, что можно измерить, представляет ценность.

Сложности с метриками вовсе не означают, что ничего нельзя улучшить. Некоторые компании выпускают софт значительно быстрее других, и причем без ущерба качеству. Значит, есть какие-то существенные отличия, и значит, улучшения должны быть возможны.

Резюме

Улучшить ваш программный продукт при помощи метрик можно и нужно. Метрики быстродействия, нагрузки, аптайма или продуктовые метрики, вроде конверсии и удержания клиентов, — ваши друзья.

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

Но не расстраивайтесь — надежда есть! Отсутствие хороших метрик для скорости разработки — это грустненько, но это не значит, что улучшения в скорости невозможны. Еще как возможны. Да, у нас остаются только субъективные качественные оценки для получения обратной связи. Однако и их бывает достаточно чтобы внедрять улучшения и понимать есть ли от них эффект. Например, одна из вещей, которую можно улучшить, это коммуникация между разработчиками и менеджментом. По ссылке выше приведены примеры, как улучшить коммуникацию, и почему на этом стоит сделать фокус.

На этом все, пишите в комментариях, что вы думаете. Удачных вам деплоев, даже по пятницам.