Пока у меня отпуск я знакомлюсь с крутой книгой от инженеров из 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
