2024 08 24 система сдержек и противовесов

·

(082/100) система сдержек и противовесов

Когда-то давно писал про работу метрик (https://t.me/chernov_sharit/510), потом мелькала мысль про тройственную ограниченность и надо её добить. Правильнее стоит назвать тему сегодня про формирование целей на основе данных.

Проблема последних 10 лет, в дополнении к повсеместному внедрения OKR вместо KPI без изменения сути, заключается в том что используются vanity metrics. Гугл предлагает перевести как тщеславные метрики, и это прям удачное именование. Компания выходит с презентацией и говорит, что через их платформу совершается 10 млн поездок в месяц. Говорит ли нам это число о чём-то? Только в случае дополнительных метрик, а именно средний чек и маржинальность. Основная проблема с ними в том, что компания изначально использует их для празднования побед, а потом происходит сдвиг метрик в цель. Закидывай всё ради роста.

Как можно делать иначе? Если одной метрики недостаточно, надо сделать их несколько. Только формировать они должны систему “лебедь, рак и щука”, чтобы мы всегда знали где проигрываем. Это не для того, чтобы стоять на месте, а для того чтобы сознательно выбирать чем мы жертвуем ради чего. Формулировка может быть типа такой: “Сейчас мы имеем X поездок с средним чеком Y и маржой Z%. Нам необходимо вырасти до X’, при этом мы готовы на более низкий чек Y’ с такой же маржой.” Звучит уже не так круто и амбициозно, да? :)

Вообще, пример хотелось привести на игрушке Poly Bridge. Там тебе для постройки моста дают бюджет, разные типы материалов (некоторые ограничивают) и допустимую нагрузку. И дальше ты сидишь и пытаешься выжать как же тут построить стабильный мост за половину бюджета.

И напоследок пример метрик для сервисов: косты на сервера, uptime и latency/throughput. В идеале, если кто-то говорит что надо сделать api/site в два раза быстрее, то одновременно бы обсуждалось насколько мы это готовы закладывать в бюджете IT (через людей или сервера).

#марафон @chernov_sharit

Обратные ссылки