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

Представьте себе, что вы пришли работать над огромным существующим продуктом, в котором есть список метрик. Ну, штук 50, чтобы наверняка. В лучшем случае они разнесены по предметным областям (техно, пользовательское поведение и пр.). В худшем - даны просто списком. У вас, скорее всего, появится много вопросов: 1. Как эти метрики связаны между собой? 2. Как понять, есть ли сейчас проблемы в качестве этих метрик? 3. Как понять, есть ли вещи, которые покрыты метриками избыточно/не покрыты ими вовсе? 4. Как вообще разобраться во всём этом великолепии?

Краткий ответ: построить дерево метрик. Это - система вертикальной связности метрик между собой, которая позволяет проследить, как самая низкоуровневая метрика влияет на ключевой показатель продукта.

В этом посте - несколько правил, чтобы строить такие деревья и эффективно работать с ними: 1. Дерево метрик сажается с головы. Сначала берёте north-star метрику продукта, а далее смотрите на все остальные. Те метрики, которые напрямую увеличивают/уменьшают norh-star станут кроной под верхушкой. Остальные будут располагаться по принципу "напрямую влияет на метрику уровня n - попадает на уровень n-1"; 2. Дерево метрик не должно иметь отдельно стоящих сучков. Речь идёт про метрики нижних слоёв без влияния на верхние. Если такие есть - их ценность стоит подвергнуть сомнению и доработать систему (выкинуть лишнюю/добавить недостающую); 3. Дерево метрик надо наряжать. Самый эффективный подход - указывать цветом у метрики, к какой предметной области она относится. Цель такой визуализации - проследить недостаток информации. Предположим, что мы отдельно прокрасили оранжевым цветом технические метрики, и увидели, что ни одна из них не влияет на перформанс продукта. Кажется, такого быть не может - надо обсудить с техлидом, как обстоят дела на самом деле; 4. Дерево метрик не надо растить в одиночку. Ходите и спрашивайте ответственные команды, на что влияют их метрики - и что влияет на них. При этом не забывайте использовать прикорм вашего дерева здравым смыслом - а то особо рьяный инженер неожиданно докажет вам, что одна метрика в его зоне ответственности влияет на все остальные.

Вы могли заметить, что принципы построения дерева отвечают на 2,5 вопроса из 4. А что насчёт качества метрик и их достаточности? Лучше всего, конечно же, собрать отдельную связь по доменам - а дерево-то тут при чём? Через дерево вы далее сможете легко мониторить качество ваших метрик и их достаточность.

Представим себе, что метрика уровня N изменилась на 20%. Связанные с ней метрики на уровне N-1 изменились незначительно или не изменились вовсе. Вот на этом уровне вы сразу видите: ага, информации не хватает. Кажется, на уровне N-1 должна прорасти ещё одна ветка, или текущие ветки выглядят жухло. Тут надо действовать от обстоятельств, но дерево уже выполнило свою задачу - создало вам прозрачность.

📝 Пишите в комментариях, какие ещё принципы построения деревьев метрик стоит использовать

📣 Делитесь этим постом, чтобы мы узнали и собрали как можно больше полезных практик под этой записью