Метрики тщеславия

Как понять, что дела идут хорошо или плохо? Как понять справляется ли команда или нет? Как померить её эффективность? Что нужно мерить, дабы увидеть объективную картинку? Если начать искать ответы на вопросы выше, то можно сформировать для себя большой достаточно список индикаторов, на которые в разные моменты времени полезно смотреть:

• 1️⃣ TTM
• 2️⃣ Lead Time
• 3️⃣ Cycle Time
• 4️⃣ Среднее кол-во багов от регресса к регрессу
• 5️⃣ Кол-во багов с продакшена при выходе нового релиза
• 6️⃣ В целом различные трекинги скорости сборки, доставки, развертки и прочего-прочего связанного с релизом и т.д.

В общем список будет всегда звучать очень убедительно и полезно. Хотя еще можно мерить кучу ненужной бороды, на которую очень интересно смотреть и можно по ней гадать и строить эвристики такие же полезные как и на кофейной гуще. Например:

• 1️⃣ Распределение багов по компонентам системы (я очень долго убеждал себя в полезности этой штуки например)
• 2️⃣ Метрики загруженности чего-то "очень" важного (например CPU build сервера)
• 3️⃣ Кол-во задач выполненных по исполнителям
• 4️⃣ Объем прироста кодовой базы
• 5️⃣ Кол-во коммитов и многие другие

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

Для себя я сформулировал следующие тезисы, дабы не допускать появления таких тщеславных метрик:

• 🎯 Следить за метрикой надо на актуальных данных. Любая ретроспективная аналитика - это результаты 50 на 50. Они могут быть как полезными, так и вредными. Всегда лучше анализировать ситуацию в настоящем моменте, а не в прошлом дабы не строить ложных выводов.
• 🎰 В частности потому что чистота данных зависит от известности и понятности правил сбора всем участникам процесса, а именно - кем, как и зачем эта метрика собирается. Данные в прошлом априори не будут иметь корректировок на этот счет. А результат достоверности может разниться иногда вплоть до 100%.
• 🕗 Если метрика нужна прям срочно - вероятно на самом деле она не нужна. И причина по которой она понадобилась - это уже индикатор большей проблемы, которую и надо раскручивать.
• 🤷 Если метрика нужна на один раз, то тоже скорее всего не нужна вовсе. Впиши любую цифру основанную на личных ощущениях туда - ничего не поменяется.
• 👆 За метрикой нужно следить. Если метрика есть, а работы с ней нет, то и метрики нет.
• 🍻 Метрика должна помогать решать проблему, если из метрики нельзя получить ответ и принять решение по проблеме - в топку такую метрику.
• 👀 У метрики должна быть понятная динамика наблюдения, т.е. если не понятно в какую сторону её изменять, то и смотреть в неё не стоит.

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

• 1️⃣ Lead Time
• 2️⃣ Размер хвоста распределения задач по типам
• 3️⃣ Кол-во задач по типу за релизный цикл

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