Обзор фреймворков GSM и QUANTS

В марте 2020 года вышла книга Software Engineering at Google в которой были представлены фреймворки GSM и QUANTS для анализа продуктивности инженеров (Engineering Productivity) в Google. Компании Google приходилось быстро расти и выходить в новые направления бизнеса, что потребовало научиться повышать продуктивность инженеров. Для этого необходимо было понять, что именно влияет на их продуктивность, выявить неэффективности в инженерных процессах и устранить обнаруженные проблемы. В Google была создана специальная исследовательская команда, сосредоточенная на изучении продуктивности инженеров. В команду вошли специалисты в области исследований разработки ПО и инженеры широкого профиля, а также социологи из разных областей, включая когнитивную психологию и поведенческую экономику. Привлечение специалистов из социальных наук позволило изучать не только программные артефакты, создаваемые инженерами, но и человеческую сторону разработки, включая личную мотивацию, структуры стимулов и подходы к управлению сложными задачами. Цель такой команды — применять подход, основанный на данных, для измерения и повышения продуктивности инженеров.

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

Какой результат вы ожидаете и почему? Даже если стремиться к нейтральности, у исследователей всегда есть предварительные ожидания. Признание этого на раннем этапе позволяет учитывать возможные предвзятости и избегать постфактум интерпретаций результатов;
Если данные подтвердят ожидаемый результат, какие действия будут предприняты? Если никакие действия не последуют, измерение не имеет смысла. Действием может быть и сохранение текущего состояния, если оно является осознанным выбором;
Если результат окажется отрицательным, будут ли предприняты соответствующие действия? Часто отрицательные результаты не приводят к изменениям решений из-за других факторов. В таких случаях измерение нецелесообразно. Этот вопрос является причиной остановки большинства исследовательских инициатив;
Кто будет принимать решение и когда? Важно, чтобы инициатор измерения имел полномочия принимать решения или действовал от имени такого лица. Цель измерения — поддержка принятия бизнес-решений. Необходимо понимать, кто принимает решение и какой формат данных для него убедителен. Несмотря на предпочтительность комбинированного подхода (интервью, анализ логов, статистика), временные ограничения могут требовать адаптации под конкретного стейкхолдера.

Ответы на эти вопросы часто приводят к выводу, что измерение не требуется, и это допустимо. Возможны следующие ситуации:

Невозможно изменить процесс или инструменты в данный момент. Ограничения по времени или финансам могут делать изменения невозможными, даже если потенциальная выгода очевидна;
Результаты скоро потеряют актуальность. Например, при планируемой реорганизации или выводе системы из эксплуатации;
Лицо, принимающее решение, не изменит свою позицию. Если невозможно предоставить данные в форме, которая будет принята, измерение теряет смысл;
Результаты будут использованы как формальное обоснование заранее принятого решения. В этом случае метрики становятся декоративными и не влияют на реальные решения;
Доступные метрики не позволяют корректно измерить проблему. Использование неточных метрик приводит к неинтерпретируемым результатам и ошибочным выводам.

Фреймворк Goals/Signals/Metrics (GSM)
В Google для построения метрик используется фреймворк Goals/Signals/Metrics (GSM).

Цель (Goal) — это желаемый конечный результат. Они формулируются на высоком уровне, исходя из того, что требуется понять, и не должны содержать ссылок на конкретные способы измерения;
Сигнал (Signal) — это то, по чему можно понять, что конечный результат достигнут. Сигналы — это то, что хотелось бы измерять, но они могут быть напрямую неизмеримыми. Сигнал — это способ понять, что цель достигнута. Между сигналами и целями нет отношения 1:1. У каждой цели должен быть как минимум один сигнал, но их может быть больше. Некоторые цели могут также использовать один и тот же сигнал;
Метрика (Metric) — это прокси для сигнала. Это то, что можно измерить на практике. Метрика может не быть идеальным способом измерения, по этой причине для одного сигнала может использоваться несколько метрик, чтобы приблизиться к его реальному значению. Ключевым требованием является обеспечение трассируемости (Traceability). Для каждой метрики должна быть возможность отследить, к какому сигналу она относится как прокси и какую цель она измеряет. Это гарантирует понимание того, какие метрики используются и зачем они измеряются.

Фреймворк GSM обеспечивает ряд важных свойств при построении метрик:

позволяет избежать эффекта уличного фонаря (Streetlight effect) за счет последовательность "Цели → Сигналы → Метрики";
помогает избежать разрастания метрик (Metrics creep) и предвзятости метрик (Metrics bias);
позволяет определить, где измерение покрывает цели, а где — нет.

Следование фреймворку GSM помогает прояснить цели измерения процесса разработки и способы их измерения. Однако даже в этом случае выбранные метрики могут не отражать полную картину, если они не захватывают нужный сигнал. В Google для валидации метрик используется качественный анализ данных, чтобы убедиться, что метрики действительно отражают предполагаемый сигнал.
Количественные метрики полезны тем, что обеспечивают масштаб и статистическую значимость. Можно измерять опыт инженеров по всей компании на протяжении длительного времени и получать надежные результаты. Однако такие метрики не дают контекста и не формируют объяснения. Количественные данные не отвечают на вопросы, почему инженер использует устаревший инструмент, почему выбирает нестандартный процесс или почему обходит установленный регламент. Эту информацию могут дать только качественные исследования, и только они позволяют определить дальнейшие шаги по улучшению процесса.

Фреймворк QUANTS
В Google анализ продуктивности разбивается на пять базовых компонентов. Эти компоненты находятся в компромиссе друг с другом, поэтому рекомендуется формулировать цели для каждого из них, чтобы не улучшать один аспект за счет ухудшения других. Для запоминания используется мнемоника QUANTS:

Quality of the code. Каково качество создаваемого кода? Достаточны ли тесты для предотвращения регрессий? Насколько архитектура снижает риски и упрощает изменения?
Attention from engineers. Как часто инженеры находятся в состоянии потока? Насколько их отвлекают уведомления? Провоцируют ли инструменты переключение контекста?
Intellectual complexity. Какова когнитивная нагрузка при выполнении задач? Насколько сложна решаемая проблема? Приходится ли инженерам работать с избыточной сложностью?
Tempo and velocity. С какой скоростью инженеры выполняют задачи? Как быстро происходят релизы? Сколько задач выполняется за определенный период?
Satisfaction. Насколько инженеры удовлетворены инструментами? Насколько инструменты соответствуют их потребностям? Удовлетворены ли они своей работой и результатами? Испытывают ли выгорание?

Engineering productivity team
В Google пришли к выводу, что наличие выделенной команды по продуктивности инженеров дает значимые преимущества для разработки программного обеспечения. Вместо того чтобы каждая команда самостоятельно искала пути повышения продуктивности, централизованная команда может сосредоточиться на решении комплексных задач на уровне всей организации. Факторы, связанные с человеческим поведением, сложно поддаются измерению, поэтому важно, чтобы специалисты глубоко понимали анализируемые данные, учитывая, что многие компромиссы при изменении инженерных процессов трудно измерить точно и они часто имеют непредвиденные последствия. Такая команда должна сохранять ориентацию на данные и стремиться минимизировать субъективные искажения.

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

Кейс по оценке влияния процесса Readability
В книге приводится кейс по оценке влияния процесса Readability на продуктивность, для этого был использован набор метрик из трех источников:

Проведен специализированный опрос, посвященный процессу Readability. Он проводился сразу после его прохождения, что позволяло получить непосредственную обратную связь и снижало эффект искажения воспоминаний (Recall bias), хотя при этом возникали эффекты недавности (Recency bias) и выборки (Sampling bias);
Использовался масштабный квартальный опрос, который не был напрямую связан с Readability, а фиксировал метрики, на которые этот процесс должен влиять;
Применялись детализированные метрики на основе логов инструментов разработки для оценки времени, затрачиваемого инженерами на выполнение конкретных задач.

В таблице ниже представлен полный перечень метрик с соответствующими сигналами и целями:

Quality of the code;Engineers write higher-quality code as a result of the readability process.;Engineers who have been granted readability judge their code to be of higher quality than engineers who have not been granted readability.;Quarterly Survey: Proportion of engineers who report being satisfied with the quality of their own code ;;The readability process has a positive impact on code quality.;Readability Survey: Proportion of engineers reporting that readability reviews have no impact or negative impact on code quality ;;;Readability Survey: Proportion of engineers reporting that participating in the readability process has improved code quality for their team ;Engineers write more consistent code as a result of the readability process.;Engineers are given consistent feedback and direction in code reviews by readability reviewers as a part of the readability process.;Readability Survey: Proportion of engineers reporting inconsistency in readability reviewers’ comments and readability criteria. ;Engineers contribute to a culture of code health as a result of the readability process.;Engineers who have been granted readability regularly comment on style and/or readability issues in code reviews.;Readability Survey: Proportion of engineers reporting that they regularly comment on style and/or readability issues in code reviews Attention from engineers;n/a;n/a;n/a Intellectual complexity;Engineers learn about the Google codebase and best coding practices as a result of the readability process.;Engineers report learning from the readability process.;Readability Survey: Proportion of engineers reporting that they learned about four relevant topics ;;;Readability Survey: Proportion of engineers reporting that learning or gaining expertise was a strength of the readability process ;Engineers receive mentoring during the readability process.;Engineers report positive interactions with experienced Google engineers who serve as reviewers during the readability process.;Readability Survey: Proportion of engineers reporting that working with readability reviewers was a strength of the readability process Tempo/velocity;Engineers are more productive as a result of the readability process.;Engineers who have been granted readability judge themselves to be more productive than engineers who have not been granted readability.;Quarterly Survey: Proportion of engineers reporting that they’re highly productive ;;Engineers report that completing the readability process positively affects their engineering velocity.;Readability Survey: Proportion of engineers reporting that not having readability reduces team engineering velocity ;;Changelists (CLs) written by engineers who have been granted readability are faster to review than CLs written by engineers who have not been granted readability.;Logs data: Median review time for CLs from authors with readability and without readability ;;CLs written by engineers who have been granted readability are easier to shepherd through code review than CLs written by engineers who have not been granted readability.;Logs data: Median shepherding time for CLs from authors with readability and without readability ;;CLs written by engineers who have been granted readability are faster to get through code review than CLs written by engineers who have not been granted readability.;Logs data: Median time to submit for CLs from authors with readability and without readability ;;The readability process does not have a negative impact on engineering velocity.;Readability Survey: Proportion of engineers reporting that the readability process negatively impacts their velocity ;;;Readability Survey: Proportion of engineers reporting that readability reviewers responded promptly ;;;Readability Survey: Proportion of engineers reporting that timeliness of reviews was a strength of the readability process Satisfaction;Engineers see the benefit of the readability process and have positive feelings about participating in it.;Engineers view the readability process as being an overall positive experience.;Readability Survey: Proportion of engineers reporting that their experience with the readability process was positive overall ;;Engineers view the readability process as being worthwhile;Readability Survey: Proportion of engineers reporting that the readability process is worthwhile ;;;Readability Survey: Proportion of engineers reporting that the quality of readability reviews is a strength of the process ;;;Readability Survey: Proportion of engineers reporting that thoroughness is a strength of the process ;;Engineers do not view the readability process as frustrating.;Readability Survey: Proportion of engineers reporting that the readability process is uncertain, unclear, slow, or frustrating ;;;Quarterly Survey: Proportion of engineers reporting that they’re satisfied with their own engineering velocity

Если вам интересно измерение и развитие продуктивности инженеров (Engineering Productivity) с использованием фреймворков GSM и QUANTS, обращайтесь к нам за помощью. Мы помогаем выстраивать системный подход по инженерной аналитике, объединяя количественные и качественные методы, чтобы не только измерять, но и объяснять причины наблюдаемых эффектов.

Мы помогаем запускать и развивать Engineering Productivity и Enabling команды, создавать внутренние платформы инженерной аналитики, применять и адаптировать фреймворки под контекст компании.

Не забывайте подписываться на наш канал Enabling.team Insights, чтобы быть следить за состоянием в индустрии.