вот да.

я забыл как звучит поговорка в оригинале, но что-то типа «if you start measuring something - you start faking/manipulating it».

Ну и куча подтверждений этому. От гугла до боинга.

должны быть определённые границы для творчества / пофигизма. иначе никак

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

это всегда так?

По моим наблюдениям как минимум часто.
Требуется очень филигранный и талантливый менеджер, который сможет побороть желание показать хорошие метрики просто манипулируя ими и пойти сложным путём, ещё и убедить команду что метрики это ещё не все.
Но я таких видел полторы штуки и они никогда не говорили про метрики внутри команды.
Это не очень правильно, но он наружу давал то, что надо, правильно интерпретированное для вышестоящих, а внутри рулил без всяких метрик. Он собственно прямо говорил, что «да, есть метрики, но это не ваша проблема, пожалуйста делайте что вы лучше всего умеете - продукт, херню с метриками я разрулю». Это двойственный путь и вообще противоречит тому, как оно должно быть, но в условиях тотального KPI он по крайней мере позволяет сохранить в команде мотивацию работать ради продукта, а не ради KPI.

Я честно скажу, я неплохо умею рисовать метрики и адаптировать их так, что минимальная безопасная работа будет показывать на бумаге отличный результат. Метод в целом простой же - берём low hang fruits, раздуваем их немного чтобы много их не искать, тщательно расписываем, до состояния ощущения что это рокет сайнс, ярко презентуем, неторопясь делаем, метрики адаптируем и все. Толку мало, что то сделано, по метрикам все просто 110 из 100.

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

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

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

не уверен, что понимаю о чем ты. кто эти люди и почему они перестают делать что-то внятное?

Ну смотри. У тебя есть метрика «кто сколько накосячил по сути». Ты же сам выше говорил, что лучший способ не косячить и не катить баги на прод - вообще не катить на прод:) ну там правда про хуйню было, но смысл то тот же.

Если мерить коммитами или фичами, то опять же начинается борьба за «да похуй, катите сейчас, у нас метрики, косяки спишем в следующий спринт, там и починим»:) и начинается вот это вращение на известном органе вокруг метрик.

это метрики курильщика

с таким отношением лучше уж действительно не мерять. ничего)

Ага, все так. При этом хорошие метрики я почти никогда не видел. Да и работать они будут только комплексе с нормальным подходом, когда метрики не давлеют над процессом. О чем я собственно и пишу:)

Кто сколько косячит - обычно видит лид или хэд, и считать это - ну такое. А вот например сколько задачи проводят на разных стадиях - это интереснее, это про поиск узких мест по Голдратту.

Ага. Но это анализ здорового человека:) Тут все очевидно и понятно, он другие задачи решает.

тут имеется в виду, кто сколько накосячил по человеку или совокупно? метрика - кол-во багов после релиза в целом? или если не привязываться к релизам, кол-во багов на проде over time?

Продукт мониторить точно надо по метрикам. А вот по человеку вести подобное точно так себе, разве что скрыто и на уровне менеджеров команды.