How to measure anything

“How to measure anything” это отличная книга, которая дает понимание, как принимать решения, моделируя их количественно используя Applied Information Economics метод.

Сразу во время чтения, я попробовал применить подход, описанный в книге, на одном из своих “pet projects” в компании.Я взял один из проектов, в моем случае это проект освоения AI code autosuggest (вроде co-pilot). Описал дилемму, те какое именно решение я пытаюсь принять, и что я собственно хочу померить. В моем случае, решение, которое я хотел принять, это стоит ли вводить эту технологию повсеместно, или оставить ее как опциональную, и пусть разработчики решают, нужна она им или нет. Для того, чтобы вводить ее повсеместно, моей команде будет нужно инвестировать время на пропитку, создание чемпионов в компании и прочее. Для того, чтобы вводить ее опционально, ничего этого не нужно.

После этого, я как subject matter expert, вместе с группой таких же экспертов, попытались понять, что же мы хотим померить, для того, чтобы мы могли принять это решение. Мы решили мерить эффективность работы, как то, от чего будет зависеть финальное решение.

Мы решили измерять эффективность работы как: производительность разработчиков в виде кол-ва закрытых story points, а также время для pull request. Те гипотеза состоит в том, что эта технология уменьшает время работы разработчиков (так как они тратят меньше времени на поиск примеров кода, например, что сказывается на кол-ве story points), а также повышает качество pull request (соответственно время для pull request возможно станет меньше). Дебаты по поводу измерений еще не окончены, но я попробую рассказать, что уже сделано и какие планы.

Я создал финансовую модель, которая четко показала насколько показатели компании изменятся (в денежном выражении), при внедрении данной технологии. Данная модель была разбита на ряд параметров (на текущий момент параметров около 5-6), и команда предложила свой 90% confidence interval для каждого из параметров. (Калиброванный тренинг мы не проходили, но я задавал наводящие вопросы, при обсуждении)

Было проведено моделирование по Monte Carlo, предполагая нормальное распеределение (тут конечно, мы не знаем, какое распределение на самом деле, возможно будет иметь смысл сделать random sampling на исторических данных и посчитать mean и standard deviation не зная распределения, в книге такие методы приведены) значений для всех параметров.

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

На текущий момент, были предложены несколько очень дешёвых экспериментов (20X дешевле, чем посчитанная количественно ценность информации), которые можно присесть на small sample разработчиков и померить изменение в производительности.

Пока что, это проект еще не окончен, и возможно, будут изменения в подходе, но сам проект используется как площадка для обкатывая AIE метода при принятии решений.

Глобально, я бы очень хотел прийти к risk/return boundary согласованной с exec командой, и использовать ее для принятии решений при выборе инвестиций. Однако, более реалистично, будет:

  1. Четко артикулировать, какое решение (дилемму) мы пытаемся решить для любого проекта, в который компания пытается инвестировать
  2. Уйти от конкретных значений при финансовой оценке проекта и перейти к вероятностным диапазонам оценок. (Те моделировать линейно и вероятностно) Я думаю, одно это изменение, сразу же заставит exec команду подумать о диапазоне risk / return, и как можно уменьшить неопределенность при принятии решений.