Тимлидов обычно натаскивают на работу с метриками команды. Там есть целый набор волшебных индикаторов, которые призваны сигнализировать о производительности нашего конвейера. Но я считаю, что тимлиду крайне полезно разбираться и в продуктовых метриках. Если высокоэффективный конвейер выпускает фигню, то на выходе мы получаем много фигни.
Не всё и не всегда получится полноценно обложить продуктовыми метриками. Однако у продукта всегда есть показатели, по которым можно узнать много интересного.
Когда жизнь преподнесла мне обязанности продакта на полставки, я понял, что почти ничего не знаю о пользователях системы, которую пилит наша команда. Люди говорят не совсем то, что делают, поэтому к душевным беседам я добавил метрики использования.
Они показали, каким функционалом люди пользуются, а каким почти нет. Я обсудил это с пользователями и понял, что часть системы можно сильно упростить, а некоторые функции вообще выкинуть. Их больше не нужно было развивать, поддерживать и тестировать.
С техлидской стороны я проделывал то же самое с устаревшими endpoint’ами. Сначала мы сняли метрики потребления, а потом плавно отключали endpoint’ы через предупреждения и прочие процессы.
Метрики становятся интересным аргументом в обсуждении задач. Новую фичу можно сделать попроще, а потом посмотреть, будут ли ей вообще пользоваться. Такой подход помогает не строить космические корабли вместо бумажных лодочек. Об этом я уже писал в материале «Не ленивый, а бережливый».
Продуктовые метрики и метрики использования дают тимлиду данные о реальном поведении пользователей. Без них легко создать невостребованную функцию или поверить непреднамеренному обману. С метриками решения о новых фичах, упрощении и удалении старого функционала становятся сильнее.