Делай как вGoogle
 Скачать 5.77 Mb.
|
|
128 Глава 6. Масштабируемое лидерство делением направлений карьерного роста ваших лидеров или планированием сотрудничества с другими командами. Подберите хорошую систему учета Существуют десятки систем учета, помогающих расставить приоритеты в работе. Некоторые опираются на использование ПО (например, специальные инструмен- ты ведения списка дел), другие — на использование ручки и бумаги (как метод «Bullet Journal», http://www.bulletjournal.com ), а третьи не зависят от реализации. Относительно последней категории большую популярность среди инженеров за- воевала книга Дэвида Аллена «Как привести дела в порядок» (М.: МИФ, 2016). Она описывает абстрактный алгоритм работы с задачами и поддержания «по- чтового ящика пустым». Попробуйте разные системы и определите, какая лучше подходит для вас. Постарайтесь найти что-то более эффективное, чем стикеры на экране компьютера. Учитесь ронять мячи Есть еще один ключевой метод управления своим временем, и на первый взгляд он выглядит чересчур радикальным. Для многих этот метод противоречит многолетним инженерным инстинктам. Как инженер вы обращаете внимание на детали: состав- ляете списки дел, проверяете, что в них не попало, проявляете точность и всегда заканчиваете начатое. Вам приятно закрывать ошибки в баг-трекере или сокращать количество необработанных входящих сообщений до нуля. Но ваши время и вни- мание как лидера лидеров находятся под постоянной атакой. Независимо от ваших стараний вы, так или иначе, начнете ронять мячи на пол — их просто слишком много. Это ошеломляет, и вы, наверное, все время чувствуете вину за это. А теперь отступим на шаг назад и посмотрим на ситуацию беспристрастно. Если падение каких-то мячей неизбежно, не лучше ли уронить некоторые из них предна- меренно, а не случайно? По крайней мере, тогда у вас появится ощущение контроля. Вот отличный способ сделать это. Мари Кондо, консультант по организационным вопросам, в книге «Магическая уборка. Японское искусство наведения порядка дома и в жизни» (М.: Эксмо, 2017) рассказала о философии эффективного наведения порядка в доме, которую с успехом можно применить к любому абстрактному беспорядку. Подумайте о своем физическом имуществе как о трех кучах. Около 20 % ваших вещей просто бесполезны (вы попользовались ими один раз и больше никогда не трогали), их очень легко выбросить. Около 60 % вещей представляют определен- ный интерес, они различаются для вас по важности, и вы используете их время от времени. И только оставшиеся 20 % ваших вещей действительно важны для вас: вы используете их постоянно, они имеют большое эмоциональное значение или, как говорит мисс Кондо, вызывают глубокую «радость», когда вы просто берете их в руки. Главная мысль ее книги состоит в том, что большинство людей неправиль- Всегда масштабируйте себя 129 но подходят к организации своей жизни: они тратят время, чтобы выбросить 20 % мусора, но оставшиеся 80 % вещей все еще создают ощущение загромождения. Она утверждает, что для наведения истинного порядка нужно определить верхние, а не нижние 20 %. Если вы сможете определить только важные вещи, вы должны выбро- сить остальные 80 %. Звучит экстремально, но довольно эффективно. Этот метод позволяет радикально избавиться от хлама. Эту философию с успехом можно применить к входящей почте или списку дел — мячам, брошенным вам. Разделите мячи на три кучи: нижние 20 % мячей, вероятно, не являются ни срочными, ни важными, и их можно смело удалить или проигнори- ровать. Средние 60 % задач, которые могут иметь ту или иную степень срочности или важности, — это смешанная куча. На вершине остаются 20 % мячей, имеющих неоспоримую важность. А теперь, работая над своими задачами, не пытайтесь взяться за верхние 80 %, иначе вы окажетесь загруженными срочными, но не важными задачами. Вместо этого вни- мательно определите мячи, которые попадают в верхние 20 %, — критические задачи, которые можете сделать только вы, — и сосредоточьтесь только на них. Позвольте себе уронить остальные 80 %. Поначалу это может показаться ужасным, но если вы намеренно уроните так много мячей, то обнаружите два удивительных обстоятельства. Во-первых, даже если вы никому не будете делегировать средние 60 % задач, ваши подчиненные заметят это и подберут их сами. Во-вторых, если что-то в этой средней куче действительно важно, оно все равно вернется к вам, рано или поздно перейдя в верхние 20 %. Вам просто нужно поверить, что задачи, не попавшие в верхние 20 %, будут решены другими или вырастут до уровня действительной важности. Между тем, сконцентрировавшись только на критически важных задачах, вы сможете распределить свое время и внима- ние так, чтобы верно реагировать на постоянно растущие обязанности вашей группы. Защитите свою энергию Мы поговорили о защите вашего времени и внимания, но в уравнении есть еще один член — ваша личная энергия. Постоянные хлопоты о масштабировании утомляют. Как в такой обстановке оставаться заряженным и оптимистичным? Отчасти ответ заключается в том, что со временем ваша общая выносливость воз- растает. В начале карьеры работа в офисе по восемь часов в день может показаться шоком: вспомните, насколько уставшими вы возвращались домой. Но, так же как при подготовке к марафону, ваш мозг и тело со временем накапливают запасы вы- носливости. Другая важная часть ответа: лидеры постепенно учатся более разумно управлять своей энергией и постоянно уделять этому внимание, приобретают умение оценивать свою энергию в любой момент и делать осознанный выбор, когда и как «подзарядить» себя. Вот несколько интересных примеров разумного управления энергией: 130 Глава 6. Масштабируемое лидерство Возьмите настоящий отпуск Выходные — это не отпуск. Требуется как минимум три дня, чтобы «забыть» о работе, и по меньшей мере неделя, чтобы почувствовать себя обновленным. Но продолжая во время отпуска проверять рабочую почту или чаты, вы перекрывае- те подпитку. Поток беспокойства прорывается в ваш разум, и все преимущества психологического дистанцирования улетучиваются. Отпуск заряжает, только если вы действительно полностью отключаетесь от работы 1 . А это возможно, только если вы создали организацию, которая может работать без вас. Просто отключитесь Решив отключиться от дел, оставьте свой рабочий ноутбук в офисе. Если на вашем личном телефоне есть рабочие контакты, удалите их. Например, если ваша компания использует G Suite (Gmail, Google Calendar и т. д.), установите эти приложения в «рабочем профиле» на личном телефоне. У вас появятся два приложения Gmail: одно для личной электронной почты, другое — для рабочей. На телефоне с Android достаточно нажать всего одну кнопку, чтобы полностью отключить рабочий профиль. Все значки рабочих приложений станут серыми, как если бы они были удалены, и вы не сможете «случайно» проверить рабочие сообщения, пока вновь не включите рабочий профиль. Сделайте выходные по-настоящему выходными Выходные не так эффективны, как отпуск, но они тоже могут немного подзаря- дить вас. Но имейте в виду, что подзарядка возможна только в том случае, если вы полностью отключитесь от общения по рабочим вопросам. Попробуйте на самом деле выйти из системы в пятницу вечером, провести выходные, занимаясь любимым делом, и войти снова в понедельник утром, когда вернетесь в офис. Делайте перерывы в течение дня В естественной среде человеческий мозг работает 90-минутными циклами 2 . Вос- пользуйтесь возможностью встать и прогуляться по офису или выйти на 10 минут на улицу. Такие маленькие перерывы, конечно, позволяют подзарядиться лишь чуть-чуть, но они могут существенно снизить уровень стресса и улучшить ваше самочувствие в течение следующих двух часов работы. Дайте себе право на день психологической разгрузки Иногда без всякой причины работа не задается. Вы могли хорошо выспаться, хорошо поесть, позаниматься спортом, и все равно у вас плохое настроение. Если вы лидер, то это ужасно. Ваше плохое настроение накаляет атмосферу, а это может привести к неверным решениям (электронные письма, которые вы не должны были отправлять, слишком суровые суждения и т. д.). Оказавшись в такой ситу- 1 Вам нужно заранее приготовить себя к тому, что во время отпуска ваша работа просто не будет выполнена. Упорный (или энергичный) труд непосредственно перед отпуском и после него смягчает эту проблему. 2 Узнать больше о циклах покоя-активности мозга можно в Википедии: https://en.wikipedia. org/wiki/Basic_rest-activity_cycle Итоги 131 ации, просто развернитесь и идите домой, объявив разгрузочный день. В такой день лучше ничего не делать, чем активно наносить урон. В конце концов, умение управлять энергией так же важно, как и умение управлять временем. Если вы освоите эти умения, то сможете перейти к следующему, более широкому циклу масштабирования ответственности и создания самодостаточной команды. Заключение Успешные лидеры берут на себя больше ответственности по мере карьерного роста (и это естественно). Если они не придумают эффективные методы, помогающие быстро принимать правильные решения, делегировать задачи другим при необ- ходимости и управлять своей повышенной ответственностью, они в итоге могут почувствовать себя подавленными. Быть эффективным лидером не означает прини- мать совершенные решения, делать все самостоятельно или работать вдвое больше. Эффективный лидер должен всегда принимать решения, всегда уходить и всегда быть масштабируемым. Итоги y Всегда принимайте решения: неоднозначные проблемы не решаются как по волшебству — все они связаны с поиском правильных компромиссов в данный момент и повторными попытками. y Всегда уходите: ваша задача как лидера состоит в том, чтобы построить органи- зацию, которая автоматически решает целый класс неоднозначных проблем без вашего присутствия. y Всегда масштабируйте себя: со временем успех порождает больше ответствен- ности, и вы должны активно управлять масштабированием своей работы, чтобы защитить свои ограниченные ресурсы личного времени, внимания и энергии. ГЛАВА 7 Оценка продуктивности инженеров Автор: Сиера Джаспен Редактор: Риона Макнамара Google — компания, управляемая данными. Большинство наших продуктов и про- ектных решений прочно опираются на данные. Решения, принятые на основе данных и соответствующих метрик, носят объективный, а не субъективный характер. Однако сбор и анализ данных о человеческой натуре имеют свои проблемы. Мы в Google обнаружили, что в сфере разработки ПО наличие команды специалистов, сосредо- точенных на продуктивности труда инженеров, очень ценно и важно, потому что компания может масштабировать и использовать идеи такой команды. Зачем оценивать продуктивность инженеров? Представьте, что вы владеете процветающим бизнесом (например, развиваете систе- му поиска в интернете) и хотите расширить его (выйти на рынок корпоративных, облачных или мобильных приложений). Для этого необходимо увеличить размер инженерной организации. Однако расходы на связь растут в квадратичной зависи- мости от роста размеров организации 1 . Вы можете нанять больше людей, но наклад- ные расходы на связь не будут расти линейно с расширением персонала. Линейно масштабировать бизнес с увеличением размеров вашей инженерной организации не получится. Есть другой способ решить проблему масштабирования: сделать каждого сотруд- ника более продуктивным. Это поможет расширить сферу бизнеса без увеличения накладных расходов на связь. Компании Google пришлось быстро осваивать новые сферы бизнеса и соответственно учить инженеров работать более продуктивно. Для этого нам нужно было понять, что делает сотрудников продуктивными, найти причины неэффективности инженер- ных процессов и исправить выявленные проблемы. Эти меры можно повторять при необходимости в процессе непрерывного улучшения и тем самым масштабировать инженерную организацию с учетом все возрастающих потребностей. 1 Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы. СПб.: Питер, 2021. — Примеч. пер. Расстановка приоритетов: что измерять? 133 Однако этот цикл мер тоже требует человеческих ресурсов. Было бы нецелесо- образно повышать продуктивность десяти инженеров в год за счет труда пятидесяти инженеров в течение года, выявляющих и устраняющих препятствия, мешающие росту продуктивности. Наша цель — не только повысить продуктивность разработки ПО, но и сделать это эффективно. Мы в Google достигли этой цели, создав команду исследователей, занимающихся вопросами повышения продуктивности инженеров. В нее вошли люди, работающие над исследованиями в области программной инженерии, инженеры-программисты общего профиля, а также социологи из разных областей, включая когнитивную психологию и поведенческую экономику. Добавление специалистов социальных наук позволило нам изучать человеческий фактор разработки ПО, включая личные мотивы, структуру стимулов и политики для управления сложными задачами. Мы стремимся оценить и увеличить продуктивность инженерного труда, используя подходы на основе данных. В этой главе мы рассмотрим, как наша исследовательская группа достигает постав- ленной цели. Все начинается с расстановки приоритетов. В разработке ПО есть много параметров, которые можно измерить, но что нужно измерить? Мы рассмотрим, как после выбора проекта исследовательская группа определяет значимые метрики, идентифицирующие проблемные этапы процесса, и как показатели для оценки увеличения продуктивности используются в Google. В этой главе мы исследуем конкретный пример, представленный языковыми ко- мандами C++ и Java: поддержку удобочитаемости. (Подробнее об удобочитаемости в главе 3.) Этот процесс был введен в первые годы существования Google, еще до того, как стали привычными средства автоматического форматирования (глава 8) и статического анализа кода (глава 9), блокирующие его отправку. Сам процесс обходится довольно дорого, потому что требует, чтобы сотни инженеров проверяли удобочитаемость кода, написанного другими инженерами. Некоторые сотрудники считали его архаичным проявлением «дедовщины», не имеющим смысла, и это была их любимая тема в обеденный перерыв. Перед языковыми командами был поставлен вопрос: стоит ли тратить время на повышение удобочитаемости? Расстановка приоритетов: что измерять? Для оценки продуктивности инженеров нужно выбрать метрики. Само измерение — дорогостоящий процесс, включающий производство измерений, анализ результатов и распространение полученных данных в компании. Такие мероприятия могут за- медлять работу инженерной организации в целом. Даже если замедления не проис- ходит, отслеживание прогресса может влиять на поведение инженеров и отвлекать их от реальных проблем. Измерения и оценка должны производиться с умом — не становиться гаданием на кофейной гуще и не отнимать время и ресурсы на измере- ние ненужного. 134 Глава 7. Оценка продуктивности инженеров Мы в Google придумали ряд вопросов, чтобы помочь командам определить, стоит ли вообще проводить измерения. Сначала мы просим людей описать в форме конкрет- ного вопроса, что они хотели бы измерить. Как показывает практика, чем конкретнее человек формулирует вопрос, тем выше вероятность, что он получит пользу от ответа. Когда к нам обратилась группа по удобочитаемости, ее вопрос был прост: окупятся ли для компании затраты на работу инженера по повышению удобочитаемости? Затем мы просим их рассмотреть следующие аспекты их вопроса: Какой результат вы ожидаете получить и почему? Не будем притворяться, что мы относимся к теме нейтрально. У нас есть свои представления о вопросе. Признав это с самого начала, мы попытаемся устранить предубеждения и не допустить объяснения результатов постфактум. Команда по удобочитаемости отметила, что причина возникновения вопроса о целесообразности дополнительной проверки кода в неуверенности. Одно время люди были уверены, что затраты на контроль удобочитаемости окупятся, но после появления автоматизированных инструментов форматирования и статического анализа эта уверенность стала неполной. Развилось убеждение, что этот процесс потерял актуальность. Он еще может давать инженерам преимущества (и резуль- таты опроса показали, что люди стремятся их получить), но неясно, стоят ли эти преимущества времени, затраченного авторами или рецензентами кода. Если данные подтвердят ожидаемый результат, какие действия будут предпри- няты? Бессмысленно что-то измерять, если по результатам измерений не будет пред- принято никаких действий. Обратите внимание, что действием может быть «под- держание текущего положения дел», если запланировано некоторое изменение, которое произойдет независимо от результатов измерений. Команда удобочитаемости дала простой ответ: если подтвердится, что выгоды от контроля удобочитаемости окупают затраты, команда сошлется на исследование и данные в сборнике часто задаваемых вопросов об удобочитаемости и объявит об этом, чтобы подтвердить ожидания. Если получится отрицательный результат, будут ли приняты соответствующие меры? Часто отрицательный результат не так влияет на принятие решение, как другие более важные факторы. В такой ситуации, возможно, стоит отложить измере- ния. Этот вопрос останавливает большинство проектов, к которым приступает наша исследовательская группа: люди, принимающие решения, заинтересованы в знании результатов измерений, но по каким-то причинам не хотят менять курс. В случае с удобочитаемостью, однако, командой было твердо обещано, что если по результатам анализа затраты перевесят выгоду или выгоды окажутся незначи- тельными, тогда команда остановит контроль удобочитаемости. Поскольку разные языки программирования имеют разные уровни зрелости инструментов форма- тирования и статического анализа, каждый язык будет оцениваться отдельно. Расстановка приоритетов: что измерять? 135 Кто будет принимать решение по полученному результату и в какой срок? Сотрудник, запрашивающий проведение измерений, должен быть уполномочен принимать решения (или действовать от имени ответственного лица). Цель из- мерения — помочь принять бизнес-решение, и важно знать, кто сделал запрос и данные в какой форме его убедят. Конечно, хорошее исследование должно включать разные подходы (от структурированных опросов до статистического анализа журналов), но время предоставления данных может быть ограничено. Поэтому измерение полезно ориентировать на лица, принимающие решения. Склонны ли они сопереживать историям из опросов? 1 Доверяют ли они резуль- татам опроса или данным из журналов? Могут ли они разобраться в особенностях статистического анализа? Если лицо, принимающее решения, не верит в форму результата в принципе, то нет смысла проводить измерение. В случае с удобочитаемостью нам были четко названы те, кто будет принимать решения. Две команды, Java и C++, напрямую сделали нам запрос на измерения, а другие языковые группы стали наблюдать, что будет 2 . Лица, принимающие решения, доверяли опыту своих инженеров в понимании удовлетворенности и важности обучения, но хотели видеть «беспристрастные числа», получен- ные из журналов и характеризующие скорость и качество кода. Мы провели качественный и количественный анализ. Эта работа не была срочной, но ее завершение было приурочено к внутренней конференции, на которой можно было бы объявить о предстоящих изменениях. В результате мы получили не- сколько месяцев. Задавая эти вопросы, мы часто обнаруживаем, что проводить измерения просто нет смысла... и это нормально! Есть много веских причин не измерять влияние инстру- мента или процесса на продуктивность. Вот несколько примеров: Нет возможности изменить процесс/инструменты прямо сейчас Этому могут мешать временные или финансовые ограничения. Представьте, что по результатам измерения переключение на более быстрый инструмент сборки сэкономит несколько часов в неделю. Но вы не станете его проводить, поскольку для перехода потребуется приостановить разработку перед важным 1 В настоящее время в отрасли с пренебрежением относятся к «анекданным» (anecdata) — историям из личного опыта, и все стремятся «руководствоваться данными». Однако истории существуют, потому что имеют большую выразительную силу. Они, в отличие от чисел, могут дать контекст и глубокое объяснение, вызывающее резонанс. Наши исследователи не принимают решений, опираясь на истории, но мы используем и поощряем такие методы, как структурированные опросы и тематические исследования, для глубокого понимания явлений и описания контекста количественных данных. 2 Java и C++ имеют наибольшую инструментальную поддержку. Для обоих языков имеются зрелые средства форматирования и статического анализа, улавливающие распространенные ошибки. Также оба финансируются в основном изнутри. Несмотря на то что другие языко- вые команды, такие как Python, тоже интересовались результатами, очевидно, что удаление контроля удобочитаемости для Python не даст никаких преимуществ, если мы не сможем показать такие преимущества для Java или C++. 136 Глава 7. Оценка продуктивности инженеров этапом финансирования. Инженерные компромиссы не оцениваются в вакуу- ме — более широкий контекст может полностью оправдывать задержку реакции на результат. Любые результаты вскоре станут недействительными из-за других факторов В качестве примера можно привести измерение характеристик процесса разработ- ки ПО в организации непосредственно перед запланированной реорганизацией или измерение суммы технического долга по устаревшей системе. Лицо, принимающее решение в этих областях, имеет твердые убеждения, и вы вряд ли сможете представить достаточное количество доказательств нужного вида, чтобы изменить их. Во многом это вопрос знания аудитории. Даже в Google мы встречаем людей с непоколебимыми убеждениями, основанными на опыте. Нам встречались и те, кто вообще не доверяет данным опросов или поддается влиянию убедительных повествований, основанных на небольшом количестве интервью, и, конечно же, те, кто доверяет только результатам анализа журналов. Во всех случаях мы стара- емся представить взгляд на истину с разных точек зрения, используя смешанные методы, но если заинтересованная сторона настаивает на использовании метода измерений, который не подходит для данной проблемы, мы откажемся в этом участвовать. Результаты будут использоваться, только чтобы потешить свое честолюбие Это, пожалуй, самая распространенная причина, по которой мы отвечаем отказом. Люди принимают решения по несколькими причинам, и совершен- ствование процесса разработки ПО — только одна из них. Например, команда инструментов выпуска новых версий в Google однажды попросила оценить за- планированное изменение в рабочем процессе выпуска версий. Было очевидно, что изменение как минимум не ухудшит текущего состояния, но авторы запроса хотели знать, будет ли это улучшение значительным или нет. Мы спросили команду: если улучшение окажется небольшим, потратят ли они ресурсы на запланированное изменение, даже если затраты не окупят себя? Ответ был «да»! Как оказалось, эти изменения не только повышали продуктивность, но также имели побочный эффект: снижали нагрузку на команду разработчиков инструментов выпуска. Единственные доступные метрики не позволяют достаточно точно оценить про- блему и могут меняться под влиянием других факторов В некоторых случаях необходимые метрики (см. следующий раздел) просто недоступны, и может возникнуть соблазн провести анализ с использованием других, менее точных метрик (например, подсчитать число строк кода). Однако любые результаты, полученные с помощью таких метрик, не будут поддаваться интерпретации. Если метрика подтверждает ранее существовавшее убеждение заинтересованных сторон, они могут приступить к реализации своего плана без учета того, что метрика не является точной мерой. Если метрика не подтверждает Выбор значимых метрик с использованием целей и сигналов 137 убеждение, ее неточность будет использована против нее и заинтересованная сторона все так же может приступить к реализации своего плана. Под успешным измерением характеристик процесса подразумевается не доказатель- ство правильности или неправильности гипотез, а предоставление заинтересованным сторонам данных, необходимых для принятия решения. Если заинтересованная сторо- на не будет использовать полученные данные, измерение можно считать неудачным. Мы должны измерять характеристики процесса, только когда предполагается, что на основе его результатов будет принято конкретное решение. Команда поддержки удобочитаемости четко объявила: если метрики покажут, что процесс приносит пользу, они опубликуют результаты, в противном случае процесс измерений будет свернут. Обратите внимание, что команда поддержки удобочитаемости имела право принять такое решение. Выбор значимых метрик с использованием целей и сигналов Приняв решение об измерении характеристик процесса, мы определяем, какие ме- трики для него использовать. Очевидно, что число строк кода — плохая метрика 1 , но чем тогда измерить продуктивность инженеров? Для создания метрик мы в Google используем модель Цели/Сигналы/Метрики (GSM, Goals/Signals/Metrics). y Цель — это желаемый конечный результат. Она на высоком уровне определяет, что вы хотите понять, и не должна содержать ссылок на конкретные способы измерения. y Сигнал — признак достижения цели. Сигналы — это то, что мы хотим измерить, но они могут оказаться неизмеримыми. y Метрика — это отражение сигнала, которое можно измерить. Возможно, метрика не идеально совпадает с сигналом, но мы считаем, что она достаточно близка к нему. Модель GSM полезна с точки зрения определения метрик. Во-первых, задавая сна- чала цели, затем сигналы и, наконец, метрики, мы предотвращаем эффект уличного фонаря. Этот термин происходит от фразы «искать ключи под уличным фонарем»: освещенные места не всегда совпадают с местом, куда упали ключи. То же верно в отношении метрик: легкодоступные и легкоизмеримые метрики не всегда соот- ветствуют нашим потребностям. 1 «Следующий шаг — измерение продуктивности программиста количеством строк кода в месяц. И этот метод оценки дорого обходится, потому что поощряет писать раздутый неэффективный код. Но сегодня меня мало интересует, насколько глупой выглядит эта единица измерения труда даже с чисто коммерческой точки зрения. Я хочу подчеркнуть, что если мы считаем количество строк кода, то должны рассматривать их не как доход, а как затраты. Общепринятая практика дошла до такого маразма, что указывает нам записывать число не в ту колонку». Эдсгер Дейкстра (Edsger Dijkstra). «On the cruelty of really teaching computing science», EWD Manuscript 1036 ( https://oreil.ly/ABAX1 ). 138 Глава 7. Оценка продуктивности инженеров Во-вторых, модель GSM помогает предотвратить искажение и смещение метрик, вынуждая нас выбирать метрики до фактического измерения результата (использо- вать принципиальный подход). Рассмотрим случай, когда метрики были выбраны без использования принципиального подхода и результаты не совпали с ожидани- ями заинтересованных сторон. В такой ситуации заинтересованные стороны могут предложить для измерения другие метрики, и мы не сможем утверждать, что новые метрики не подойдут! Модель GSM заставляет нас выбирать метрики, способные измерять цели. Именно такие метрики заинтересованные стороны считают самыми подходящими. Наконец, модель GSM может показать нам области охвата измерений. Запуская процесс GSM, мы перечисляем все цели и для каждой определяем сигналы. Как мы увидим в примерах, не все сигналы измеримы, и это нормально! С помощью GSM мы определяем, что именно не поддается измерению, и принимаем решение, как действовать дальше. При выборе метрик важна поддержка контроля — возможность проследить каждую метрику обратно до сигнала, который она отражает, и цели, которую она пытается измерить. Это дает нам уверенность, что мы знаем, какие метрики измеряем и зачем. Цели Цель должна быть обозначена в терминах, не относящихся к метрикам. Сами по себе цели не поддаются измерению, но хороший набор целей — это то, с чем все могут согласиться, прежде чем переходить к сигналам, а затем к метрикам. Определение правильного набора целей может показаться простой задачей: команда наверняка знает цели своей работы! Однако наша исследовательская группа обнару- жила, что люди часто забывают включить в этот набор все возможные компромиссы продуктивности, которые могут привести к ошибочным оценкам. Представьте, что команда была настолько сосредоточена на том, чтобы сделать про- верку удобочитаемости быстрой, что забыла о качестве кода. Команда включила в измерения оценки, учитывающие время, необходимое для прохождения процесса рецензирования, и степень удовлетворенности инженеров этим процессом. Один из членов команды даже предложил: «Рецензирование кода можно сделать очень быстрым: надо полностью удалить этот этап». Конечно, это пример крайности, однако команды постоянно игнорируют компро- миссы при измерении: они настолько сосредоточены на увеличении скорости, что забывают измерить качество (или наоборот). Для борьбы с этой забывчивостью наша исследовательская группа делит продуктивность на пять основных аспектов, которые находятся в противоречии друг с другом. Мы призываем команды сверять с ними свои цели, чтобы ничего не упустить. Запомнить все пять аспектов помогает аббревиатура QUANTS: Цели 139 Quality of the code (качество кода) Как определяется качество кода? Достаточно ли хорошо тесты справляются с предотвращением регрессий? Насколько хорошо архитектура способствует снижению рисков и изменений? Attention from engineers (внимание инженеров) Как часто инженеры полностью включаются в работу? Как часто им приходится отвлекаться на уведомления? Помогает ли инструмент легко переключать вни- мание инженера? Intellectual complexity (интеллектуальная сложность) Какая когнитивная нагрузка требуется для выполнения задания? Какова вну- тренняя сложность решаемой задачи? Приходится ли инженерам справляться с избыточной сложностью? Tempo and velocity (темп и скорость) Насколько быстро инженеры справляются со своими задачами? Как быстро они могут выпускать новые версии? Сколько задач они решают за определенный период? Satisfaction (удовлетворенность) Насколько инженеры удовлетворены своими инструментами? Насколько хорошо инструмент соответствует потребностям инженеров? Насколько ин- женеры удовлетворены своей работой и конечным продуктом? Чувствуют ли они выгорание? Для оценки процесса поддержки удобочитаемости, наша исследовательская группа совместно с командой удобочитаемости определила несколько целей продуктив- ности процесса: Качество кода Участвуя в процессе повышения удобочитаемости инженеры пишут более ка- чественный и более согласованный код и вносят свой вклад в культуру едино- образия кода. Внимание инженеров Повышение внимания инженера в процессе контроля удобочитаемости не являет- ся целью. Это нормально! Для принятия компромиссного решения необязательно учитывать все пять аспектов продуктивности. Интеллектуальная сложность Участвуя в процессе контроля удобочитаемости, инженеры изучают кодовую базу и лучшие практики программирования в Google, а также получают советы наставников. Темп и скорость Благодаря повышению удобочитаемости инженеры справляются с задачами быстрее и эффективнее. 140 Глава 7. Оценка продуктивности инженеров Удовлетворенность Инженеры видят пользу от контроля удобочитаемости и положительно оцени- вают свое участие в нем. Сигналы Сигналы помогают нам узнать, достигли ли мы своих целей. Не все сигналы изме- римы, и между сигналами и целями нет прямой связи. У каждой цели должен быть хотя бы один сигнал, но их может быть и больше. Также некоторые цели могут иметь общий сигнал. В табл. 7.1 перечислены некоторые примеры сигналов, использовав- шиеся для оценки процесса контроля удобочитаемости. Таблица 7.1. Сигналы и цели Цели Сигналы Инженеры пишут более качественный код Инженеры, получающие отзывы о своем коде, оценивают свой код как более качественный Инженеры изучают кодовую базу и лучшие практики программирования в Google Инженеры отмечают, что процесс проверки удобочитаемо- сти дает им новые знания Инженеры получают советы наставников Инженеры отмечают положительное влияние обще- ния с опытными инженерами, выступающими в роли рецензентов Инженеры справляются с задачами быстрее и эффективнее Инженеры считают, что их продуктивность выше, чем у коллег. Изменения, внесенные инженерами, прошед- шими проверку, воспринимаются быстрее и проще, чем изменения, написанные другими инженерами Инженеры видят пользу от процесса проверки удобочитае- мости и положительно оценивают свое участие в нем Инженеры считают процесс контроля удобочитаемости полезным Метрики Метрики определяют, как будут измеряться сигналы, и сами по себе являются из- меримым отражениями сигналов, поэтому не считаются идеальными оценками. По этой причине сигнал может иметь несколько метрик, обеспечивающих его более точное представление. Например, чтобы оценить, насколько быстрее читается код инженера, участвующего в контроле удобочитаемости, можно использовать комбинацию из данных опросов и журналов. Ни одна из этих метрик не передаст истинной картины. (Человеку свойственно ошибаться, а метрики из журналов могут неточно измерять время, за- траченное инженером на просмотр фрагмента кода, или искажаться неизвестными факторами, действовавшими в тот момент, такими как размер или сложность кода.) Но если эти метрики показывают разные результаты, это прямо говорит о том, что одна из оценок, возможно, неверна и мы должны продолжить исследования. Если Использование данных для проверки метрик 141 же их результаты одинаковы, мы испытываем уверенность в том, что достигли какой-то истины. Кроме того, некоторые сигналы могут не иметь соответствующих им метрик на опре- деленном этапе. Рассмотрим пример. Академическая литература предлагает множе- ство вариантов оценок качества кода, но ни один из них не является по-настоящему полноценным. Занявшись исследованием процесса контроля удобочитаемости, мы могли использовать метрику, плохо отражающую сигнал, и затем принять решение на ее основе или просто признать, что на данном этапе ее нельзя измерить. В итоге мы решили не учитывать эту метрику как количественную оценку, хотя и просили инженеров самим оценить качество их кода. Следование модели GSM — это отличный способ прояснить цели оценивания не- коего процесса и порядок измерения. Мы в Google используем качественные данные для проверки наших метрик, чтобы убедиться, что они достаточно полно отражают предполагаемый сигнал и охватывают процесс полностью. Использование данных для проверки метрик Однажды мы создали метрику для оценки средней задержки работы инженера из-за ожидания завершения сборки. Цель состояла в том, чтобы зафиксировать «типичное» время ожидания. Мы провели выборочное исследование. Согласно методике исследо- ваний, инженеры должны были отвлекаться от выполнения интересующей их задачи, чтобы ответить на несколько вопросов. Как только инженер запускал сборку, мы автоматически отправляли ему небольшой список вопросов о том, какие задержки на сборку он ожидает, опираясь на личный опыт. Однако в нескольких случаях ин- женеры ответили, что еще не начали сборку! Оказалось, что инструменты запускали сборку автоматически и инженеры не тратили время на ожидание результатов и это не «засчитывалось» в «типичную» задержку. Затем мы скорректировали метрику, чтобы исключить подобные сборки 1 Количественные метрики полезны, потому что позволяют оценить масштаб. Вы можете измерить опыт инженеров по всей компании за длительный период и быть уверенными в результатах. Однако они не предоставляют никакой контекстной или описательной информации. Количественные показатели не объясняют, почему инженер использовал устаревший инструмент для выполнения своей задачи, вы- брал необычный рабочий процесс или отказался от стандартного процесса. Только качественные исследования могут дать такую информацию и позволяют получить представление о возможных шагах по улучшению процесса. Теперь рассмотрим сигналы, представленные в табл. 7.2. Какие метрики можно было бы использовать для измерения каждого из них? Некоторые из этих сигналов можно 1 Наш опыт работы в Google показывает, что когда количественные и качественные показа- тели расходятся, это часто объясняется тем, что количественные показатели не отражают ожидаемый результат. 142 Глава 7. Оценка продуктивности инженеров измерить методом анализа журналов. Другие можно измерить только с помощью опроса. Третьи вообще могут оказаться неизмеримыми — например, как измерить фактическое качество кода? В итоге, исследуя влияние процесса контроля удобочитаемости на продуктивность, мы получили комбинацию метрик из трех источников. Первый источник — резуль- таты опроса конкретно о процессе. Вопросы задавались людям, завершившим этот процесс. Их ответы позволили получить прямую обратную связь о процессе. Как мы предполагали, это должно было избавить нас от предвзятости в отзывах 1 , хотя и вводило некоторую предвзятость, обусловленную временем 2 и ограниченностью выборки 3 . Второй — результаты крупномасштабного квартального опроса, который не был специально посвящен удобочитаемости; его целью было получение метрик, которые должны влиять на процесс контроля удобочитаемости. И третий — де- тализированные метрики из журналов инструментов разработчика, помогающие определить, сколько времени требовалось инженерам для выполнения конкретных задач 4 . Полный список метрик с соответствующими сигналами и целями представ- лен в табл. 7.2. Таблица 7.2. Цели, сигналы и метрики QUANTS Цель Сигнал Метрика Качество кода Инженеры пишут более качественный код Инженеры, получающие отзывы о своем коде, оценивают свой код как более качественный Ежеквартальный опрос: доля инжене- ров, сообщивших, что удовлетворены качеством своего кода Процесс контроля удобочитаемости оказывает положительное влияние на качество кода Опрос о процессе: доля инженеров, сообщивших, что проверки удобочи- таемости не влияют или отрицательно влияют на качество кода Опрос о процессе: доля инженеров, сообщивших, что участие в процессе контроля удобочитаемости улучшило качество кода их команды 1 Под предвзятостью здесь понимается предвзятость памяти. Люди чаще вспоминают особенно интересные или разочаровывающие события. 2 Предвзятость, обусловленная временем событий, — это еще одна форма предвзятости памяти, когда люди лучше помнят свой последний опыт. В данном случае они, поскольку только что успешно завершили процесс, могут испытывать особенно яркие положительные эмоции. 3 Поскольку в опросе участвовали только те, кто завершил процесс, мы не учитывали мнение тех, кто этот процесс еще не завершил. 4 Есть соблазн использовать такие метрики для оценки отдельных инженеров или даже для определения высоких и низких показателей эффективности. Однако это было бы контр- продуктивно. Если для оценки эффективности использовать метрики продуктивности, инженеры быстро поймут это и такие метрики перестанут быть полезными для измерения и повышения продуктивности во всей организации. Единственный способ заставить эти метрики работать — оценивать ими не индивидуумов, а группы. Использование данных для проверки метрик 143 QUANTS Цель Сигнал Метрика Инженеры пишут более согласован- ный код Инженеры получают постоянную обратную связь и рекомендации от рецензентов Опрос о процессе: доля инженеров, сообщивших о несоответствии между комментариями рецензентов и крите- риями удобочитаемости Инженеры вносят свой вклад в куль- туру единообразия кода Инженеры регулярно получают комментарии, касающиеся проблем в оформлении и/или удобочитаемо- сти кода Опрос о процессе: доля инженеров, сообщивших, что регулярно получают комментарии, касающиеся проблем в оформлении и/или удобочитаемости кода Внимание инженеров Не рассмотрено Не рассмотрено Не рассмотрено Интеллек- туальная сложность Инженеры изуча ют кодовую базу и лучшие практики программирования в Google Инженеры отмечают, что процесс контроля удобочитаемости дает им новые знания Опрос о процессе: доля инженеров, сообщивших, что они узнали что-то новое не менее чем в четырех акту- альных темах Опрос о процессе: доля инженеров, сообщивших, что обучение или при- обретение опыта является сильной стороной процесса контроля удобо- читаемости Инженеры получают советы наставников Инженеры отмечают положитель- ное влияние общения с опытными инженерами, выступающими в роли рецензентов Опрос о процессе: доля инженеров, со- общивших, что работа с рецензентами является сильной стороной процесса контроля удобочитаемости Темп / скорость Инженеры работают более продуктивно Инженеры чувствуют себя продуктив- нее коллег Ежеквартальный опрос: доля инже- неров, сообщивших, что они достигли высокой продуктивности Инженеры отмечают, что завершение процесса контроля удобочитаемости положительно повлияло на скорость их работы Опрос о процессе: доля инженеров, сообщивших, что отсутствие контроля удобочитаемости снижает скорость работы команды Изменения, внесенные инженерами, прошедшими проверку, воспри- нимаются быстрее и проще, чем изменения, написанные другими инженерами Данные из журналов: среднее время обзора изменений, внесенных инженерами, участвовавшими и не участвовавшими в процессе контроля удобочитаемости Изменения, внесенные инженерами, прошедшими проверку, легче пре- одолевают процесс рецензирования, чем изменения, написанные другими инженерами Данные из журналов: среднее время рецензирования изменений, внесен- ных инженерами, участвовавшими и не участвовавшими в процессе контроля удобочитаемости 144 Глава 7. Оценка продуктивности инженеров QUANTS Цель Сигнал Метрика Изменения, внесенные инженерами, прошедшими проверку, быстрее проходят процесс рецензирования, чем изменения, написанные другими инженерами Данные из журналов: среднее время утверждения изменений, внесенных инженерами, участвовавшими и не участвовавшими в процессе контроля удобочитаемости Проверка удобочитаемости не оказывает отрицательного влияния на скорость работы Опрос о процессе: доля инженеров, сообщивших, что проверка удобо- читаемости отрицательно влияет на скорость их работы Опрос о процессе: доля инженеров, сообщивших, что рецензенты быстро давали ответы Опрос о процессе: доля инженеров, сообщивших, что своевременность проверок была сильной стороной про- цесса контроля удобочитаемости Удовлетво- ренность Инженеры видят пользу от процесса контроля удобочита- емости и положи- тельно оценивают свое участие в нем Инженеры считают проверку удобочи- таемости в целом полезным опытом Опрос о процессе: доля инженеров, со- общивших, что они получили в целом положительный опыт от участия в про- цессе контроля удобочитаемости Инженеры оценивают процесс конт- роля удобочитаемости как стоящий Опрос о процессе: доля инженеров, сообщивших о целесообразности про- цесса контроля удобочитаемости Опрос о процессе: доля инженеров, сообщивших, что качество проверки удобочитаемости является сильной стороной процесса Опрос о процессе: доля инженеров, сообщивших, что тщательность проверки является сильной стороной процесса Инженеры не считают процесс контроля удобочитаемости раз- очаровывающим Опрос о процессе: доля инженеров, сообщивших, что процесс контроля удобочитаемости является малопонят- ным, непрозрачным, медленным или разочаровывающим Ежеквартальный опрос: доля инжене- ров, сообщивших, что они удовлетво- рены скоростью своей работы Итоги 145 Принятие мер и оценка результатов Вспомним, что нашей целью в этой главе была выработка мер, способствующих увеличению продуктивности. Проводя исследования, наша команда всегда опре- деляет список рекомендаций о направлениях дальнейшего совершенствования. Мы можем предложить добавить в инструменты новые возможности, уменьшить задержки в инструментах, улучшить документацию, избавиться от устаревших процессов или даже изменить структуру стимулов для инженеров. В идеале наши рекомендации основаны на «использовании инструментов»: нет смысла говорить инженерам, что они должны изменить процесс или мнение, если их инструменты не позволяют этого сделать. Вместо этого мы всегда предполагаем, что инженеры оценят соответствующие компромиссы, если у них будут все необходимые данные и подходящие инструменты. Наше исследование показало, что в целом проверка удобочитаемости — стоящий процесс: инженеры, прошедшие его, были удовлетворены и чувствовали, что из- влекли пользу. Журналы показали, что владение навыками удобочитаемости помогло инженерам научиться быстрее проверять свой код даже при меньшем участии ре- цензентов. Также исследование выявило направления совершенствования процесса: инженеры определили его болевые точки. Языковые группы воспользовались этими рекомендациями, усовершенствовали инструментарий и сделали процесс более быстрым, прозрачным и комфортным для инженеров. Заключение Мы в Google обнаружили, что наличие команды специалистов по продуктивности дает широкие преимущества в сфере программной инженерии: каждой команде не требуется определять свой курс в стремлении увеличить продуктивность, если цен- трализованная команда может намного полнее сосредоточиться на решении таких проблем. Как известно, человеческий фактор, как и компромиссы, трудно измерить, и для экспертов важно понимать анализируемые данные. Команда специалистов по продуктивности должна основывать свои рекомендации на данных и стремиться устранить предвзятость. Итоги y Перед измерением продуктивности узнайте, будет ли использоваться полученный результат для принятия решений независимо от того, является ли он положи- тельным или отрицательным. Если не предполагается делать никаких выводов по результатам, вероятно, нет смысла что-то измерять. y Выберите метрики, используя модель GSM. Хорошая метрика — это разумное от- ражение сигнала. Ее можно проследить обратно до ваших первоначальных целей. 146 Глава 7. Оценка продуктивности инженеров y Выберите метрики, охватывающие все продуктивности (QUANTS). Этим вы гарантируете, что не улучшите один аспект (например, скорость разработки) за счет другого (например, качества кода). y Качественные метрики — тоже метрики! Подумайте о создании механизма опроса для выявления убеждений инженеров. Качественные метрики также должны соответствовать количественным метрикам. Если они противоречат друг другу, скорее всего, количественные метрики неверны. y Старайтесь вырабатывать рекомендации, влияющие на рабочий процесс раз- работчика и структуру стимулов. Несмотря на то что иногда приходится реко- мендовать дополнительное обучение или улучшение документации, изменения более вероятно будут применены, если они повлияют на повседневные привычки разработчика. |