[1/2] Measuring Engineering Productivity (from Software Engineering at Google) (Рубрика Productivity)

Пока у меня отпуск я знакомлюсь с крутой книгой от инженеров из Google, где они преоткрывают завесу тайны над своими инженерной культурой, процессами и практиками. Книга мне нравится и я решил поделиться актуальной главой про то, как в Google подходят к измерению инженерной продуктивности и вот основные мысли из этой главы

• Google - это data-driven компания, где решения принято строить на основе объективной информации, а не субъективных мнений
• При росте бизнеса растет и инженрная команда, но если организация растет условно линейно, то затраты на коммуникацию растут квадратично (можно вспомнить количество ребер в полном графе - n * (n-1) / 2). Поэтому мы не можем просто масштабировать организацию линейно - надо уметь делать каждого инженера более продуктивным
• Для повышения продуктивности надо уметь находить неэффективности в инженерных процессах и фиксить найденные проблемы. Для этого в Google собрали отдельную команду исследователей, изучающих инженерную продуктивность. В этой команде есть как инженеры, так и social scientists из множества областей, включая когнитивную психологию и поведенческую экономику. Эти ученые изучают человеческую сторону инженерных процессов
• Эта команда очень щепитильна к темам своих исследований - померить можно конечно многое, но сначала надо ответить на вопрос, а стоит ли вообще это измерять. И у них есть особый процесс для триажа (triage), где они задают вопросы командам, которые пришли к ним с запросом на исследование -- What result are you expecting, and why? - этот вопрос позволяет понять изначальные предубеждения и учесть их при оценке эксперимента -- If the data supports your expected result, what action will be taken? - есть смысл измерять что-то, если этот приведет к каким-то решениям и действиям -- If we get a negative result, will appropriate action be taken? - если негативный результат исследования не повлияет на решение, то проводить исследования тоже не стоит -- Who is going to decide to take action on the result, and when would they do it? - надо понимать кто ЛПР (лицо принимающее решение) и имеет ли он отношение к заказу исследования. Надо понимать какие подходы к исследованию этот ЛПР считает валидными - ему нужны количественные данные, качественные (в виде интервью), он верит результатам опросов или доверяет только данным из логов систем (activity based stats). В общем, это совет из серии того, что надо знать свою аудиторию и ее потребности:) Если вовремя задать эти вопросы, то многие измерения просто не стоят того, например, авторы приводят такие примеры

• You can't afford to change the process/tools right now
• Any results will soon be invalidated by other factors
• The results will be used only as vanity metrics to support something you were going to do anyway
• The only metrics available are not precise enough to measure the problem and can be confirmed by other factors

• Дальше авторы рассказывают про свой подход GSM (goals - signals - metrics) для -- Goal - это ожидаемый конечный результат, он формулируется в высокоуровневых терминах и не содержит отсылок к тому, как его измерять -- Signal - это то, как вы поймете, что результат достигнут. Его бы вы хотели измерить, но не всегда это просто -- Metric - это прокси для сигнала. Это то, что мы реально можем померить, может быть это не идеальное измерение сигнала, но достаточно близкое

В качестве примера исследования авторы говорят про процесс readability review, который принят в Google. По-факту, это подход к тому, чтобы кодовая база имела единообразный стиль и вид. Этот процесс пришел из ранних лет Google и напоминает обычное code review, но фокус в котором не на семантику изменений, а на идиоматичность использования кода. Исследование решили провести потому, что было мнение, что современные линтеры и статические анализаторы могут выдавать хорошие результаты и без привлечения людей. Продолжение будет в следующем посте.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes