[Перевод] Обзор продуктивности разработчиков от McKinsey
Не так давно компания McKinsey опубликовала статью, в которой утверждалось, что они могут измерить продуктивность разработчиков. Этот текст вызвал определённый резонанс, но я не видел, чтобы кто-то подробно комментировал содержание. Я решил, что это будет полезно сделать.
Я буду писать так, как будто авторы обратились ко мне за технической рецензией на свою статью. Можете считать это открытым письмом.
Дорогая Чандра и команда,
Спасибо, что предложили мне написать рецензию к вашей статье. Вы правы, полагая, что эта область представляет для меня особый интерес; я много размышлял на эту тему.
Я прочитал вашу статью и отметил некоторые важные моменты, о которых буду говорить ниже. Это важная тема, а McKinsey — известная компания, к которой прислушиваются многие опытные технические специалисты; поэтому я хочу помочь вам написать статью, которую они сочтут точной и полезной. Заранее прошу прощения, что отзыв получился таким длинным и подробным; я старался охватить многое, и я действительно хочу, чтобы у вас получилась отличная статья.
В процессе знакомства со статьёй я отметил несколько слабых мест, фактических ошибок и тем для дальнейшего изучения. Я также позволил себе выделить некоторые стилистические или редакторские проблемы, которые вы, возможно, захотите решить. К сожалению, вы заметите, что я не согласен с вашими основными аргументами, поэтому в конце я предлагаю несколько альтернативных предложений по эффективному измерению и развитию команды разработки.
Прежде чем мы начнём, я не мог не отметить, что все пять авторов статьи — мужчины. Я удивлён, что в такой масштабной компании, как McKinsey, не нашлось ни одной женщины для совместной работы над статьёй, которая адресована разработчикам обоих полов. Возможно, вам стоит подумать об этом в следующий раз.
Разработка программного обеспечения недостаточно измеряема?
В начале статьи вы утверждаете, что разработка программного обеспечения недостаточно измеряема. Я не совсем понимаю, как вы пришли к такому выводу. Вы множество раз делаете это утверждение без каких-либо доказательств, поэтому позвольте мне предложить контраргумент.
Разработка программного обеспечения — один из самых тщательно анализируемых и измеряемых видов бизнес-деятельности. Исторически, начиная с 1960-х и 70-х годов, разработка программного обеспечения была дорогим и довольно рискованным занятием. Сначала это было связано со стоимостью вычислительной техники и оборудования; затем, когда эта стоимость снизилась, взлетели зарплаты программистов, и речь уже зашла о ФОТ (фонд оплаты труда).
Любое рискованное и/или дорогостоящее мероприятие имеет смысл подвергать тщательному анализу, и, к сожалению, для индустрии программного обеспечения мы применили те же редукционистские модели, которые работали в промышленности — гражданском строительстве и фабричном производстве, — такие как диаграммы Ганта, выравнивание ресурсов и другие инструменты индустриальной эпохи научной организации производства. Предположение о том, что разработка программного обеспечения имеет такую же снижаемую сложность, как и сборка автомобиля, лежит в основе проблемы производительности разработчиков.
Движение agile зародилось в 1990-х годах вследствие разочарования плохими результатами многолетних программ работы — даже если всё было спланировано, измерено и проверено до мельчайших деталей, компании-разработчики всё равно умудрялись превышать бюджеты и поставлять не то, что нужно. Нельзя сказать, что эта эпоха страдала от недоизмеренности; от неправильных измерений — вполне. Есть разные способы измерения разработки программного обеспечения, которые позволяют отслеживать производительность и выявлять проблемные области, — о недостатке измеренности речи не идёт!
Если перейти к делу, то я вижу два основных ошибочных тезиса, к которым я буду возвращаться в своей статье:
Разработка программного обеспечения — это деятельность, которая сокращается со временем, и её можно измерить с помощью редукционистских инструментов.
Разработка программного обеспечения — это прежде всего написание кода, и всё, что не связано с кодированием, — это избыточные расходы, которые нужно стремиться сокращать.
Далее в статье я объясню, почему оба эти утверждения неверны.
Инструменты генеративного искусственного интеллекта делают разработчиков вдвое быстрее?
В своем вступлении вы делаете несколько утверждений. Я выделю два из них — думаю, это поможет вам понять, где в статье есть другие слабые места.
Инструменты генеративного искусственного интеллекта могут позволить разработчикам создавать код в два раза быстрее. Я не знаю, поскольку не проводил измерений и не изучал исследования, но я поверю вам на слово. Однако после трёх десятилетий практического опыта разработки во многих больших и малых организациях, с использованием многих языков программирования, парадигм и технологий, во многих сферах бизнеса;, а также консультирования в бесчисленных других, я могу с уверенностью утверждать, что большая часть программирования — это не написание кода.
Большая часть программирования — это:
изучение бизнес-области,
погружение в проблематику,
оценка возможных решений,
подтверждение предположений через обратную связь и эксперименты,
выявление, оценка и удовлетворение межфункциональных потребностей, таких как соответствие требованиям, безопасность, доступность, устойчивость, удобство использования;
обеспечение согласованности в масштабе;
предвидение возможных векторов изменений без чрезмерной инженерии;
оценка и выбор подходящих технологий;
выявление и использование уже существующих решений — как внутренних, так и сторонних.
Здесь я лишь рассуждаю поверхностно. Как видите, написание кода — лишь скромная часть; так что использование генеративного искусственного интеллекта для ускорения этого процесса, хотя и полезно, но вряд ли «делает разработчиков вдвое быстрее».
Первые результаты многообещающие?
В своей книге «Думай медленно… Решай быстро» профессор Дэниел Канеман вводит Закон малых чисел. Это когда исследователи склонны делать обобщения на основе небольших наборов данных. Он называет это ошибочной интуицией.
Предоположим, у вас 20 исследований — что может показаться большим количеством для консалтингового бизнеса, но статистически это всё равно малозначимо. Есть и другие методологические проблемы:
Похоже, нет никакой контрольной базы. Аналогичные команды, в которых вы не применяли этот метод, выступают в качестве точки отсчёта, или вы пробовали что-то другое в качестве альтернативной гипотезы.
Вы не учитываете эффект Хоторна, согласно которому команды ведут себя по-другому, когда знают, что за ними наблюдают, хотя это и оспаривается.
Похоже, вы не выделяете эти показатели. Что ещё могло происходить в то время, что могло бы объяснить эти улучшения? Является ли этот подход причинно-следственным, просто корреляционным или случайным?
Я понимаю, что это обычная статья, а не рецензированная, но представление новоиспечённой методологии как демонстрирующей «многообещающие результаты» на основе фактически эпизодических свидетельств может ввести в заблуждение.
У DORA и SPACE есть авторы!
Говоря об академической строгости, вы, как и я, наверняка являетесь поклонником исследования DORA Accelerate и более поздней модели SPACE. Но вы не приводите в пример доктора Николь Форсгрен — ведущего исследователя обеих инициатив, или кого-либо из её соавторов. Доктор Форсгрен приложила значительные усилия к первоначальным исследованиям State of DevOps Report, проведённым Puppet Labs — что привело к появлению этого обоснованного исследования и созданию DORA в течение нескольких лет.
Это исследование было изучено, проанализировано и раскритиковано отраслевыми аналитиками, и оно выдержало тщательную проверку. Это практически единственное независимое и академически обоснованное исследование agile-методов, которое у нас есть. К сожалению, в истории нашей индустрии есть проблема вытеснения женщин, участвующих в разработке программного обеспечения, поэтому я полагаю, что вы исправите это во время следующего пересмотра.
Анализ вклада?
Весь этот сегмент, который кажется краеугольным камнем статьи, к сожалению, просто ошибочен. Он приводит к заблуждению о том, что разработка программного обеспечения подобна строительству стены, где можно измерить, кто уложил больше кирпичей, или чья работа самая аккуратная и нуждается в наименьшем количестве исправлений. Недавно я написал статью, которая иллюстрирует, насколько обманчивыми могут быть показатели индивидуального вклада, особенно для более опытных разработчиков. Ниже я расскажу об этом подробнее.
Второе заблуждение заключается в утверждении, что программирование — это в основном написание кода. По моему опыту, кодинг — это, как правило, самая лёгкая часть работы. Это не значит, что его значение нужно преуменьшать; написание хорошего кода требует опыта. В частности, чтобы писать меньше кода, требуются долгие годы практики: оставаться сосредоточенным на ближайшей цели, знать язык, его библиотеки и экосистему настолько хорошо, чтобы быть способным сделать выбор, который сохранит код компактным.
Иногда кода пишется больше, чем нужно, «на всякий случай», или потому, что вы не знаете, что есть более простой алгоритм, или что он уже реализован в основных библиотеках. Это простой способ оценить уровень опыта разработчика: те, кто вносит меньше кода для решения одной и той же задачи или даже удаляет ненужный или избыточный код, часто являются вашими самыми ценными разработчиками.
Дать возможность этим самым ценным разработчикам писать код?
И в этом суть всей статьи. Продуктивность самых ценных разработчиков повышается в 10 раз, если дать возможность кодить другим разработчикам! Зачастую наименее полезная вещь, которую они могут делать, — это писать код самостоятельно.
Goldman-Sachs оценивает людей по воздействию и влиянию, и баланс между ними меняется по мере продвижения по карьерной лестнице. На ранних этапах карьеры основное внимание уделяется воздействию — тому, что и как они производят. Позже речь идёт о том, каким образом они влияют на окружающих, причём не только сверху и снизу, но и по всей организации. Старшие сотрудники вознаграждаются за создание большой сети контактов и умение добиваться поставленных целей.
Похоже, вы принимаете упрощённую модель, в которой старшие сотрудники просто делают то же, что и младшие, но в большем объёме; что означает, что их цель — не отрывать рук от клавиатуры. Весь смысл статьи в том, что лучшие разработчики должны делать, а не думать или поддерживать.
Далее вы делаете предположение, что бэклог — это продукт. Конечно, можно использовать Jira или Azure DevOps для измерения метрик процесса, таких как время выполнения или пропускная способность, и для построения накопительной диаграммы потока, но не имеет смысла использовать их для индивидуального контроля.
Реальность легко описать, но трудно измерить:
Думайте больше, делайте меньше, сокращайте время разработки.
Не допускайте ненужных усложнений, чтобы вы могли быстро двигаться и адаптироваться.
Позвольте мне привести несколько примеров того, как полезно сохранять небольшие масштабы.
Когда Facebook приобрела WhatsApp с её 500 миллионами активными пользователями, в WhatsApp было всего 13 инженеров. (Это также свидетельствует о силе Erlang).
Реляционная база данных SQLite работает практически на всех вычислительных устройствах на планете: телефонах, планшетах, браузерах, серверах, ноутбуках. У нее миллионы автотестов и всего три основных разработчика.
В 1999 году два шведских студента написали с нуля полностью совместимый с J2EE сервер приложений под названием Orion, используя новые возможности Java 1.3. Скомпилированный код занимал ~6 Мб, в то время как IBM WebSphere загружался с огромным объемом в 500+ Мб. По производительности Orion сравнялся с конкурентами от IBM, Oracle, BEA и других компаний. Он делал за секунды то, что на других серверах занимало минуты. В конце концов Oracle купила копию кода за огромную, неразглашенную сумму, и он заменил Oracle App Server.
Внутренние и внешние циклы?
Я нахожу вашу модель внутренних и внешних циклов запутанной. Они определенно не отражают мой опыт качестве разработчика корпоративного программного обеспечения, которые, как я предполагаю, являются вашей целевой аудиторией.
Идея о том, что аудит безопасности или соответствия требованиям является отдельным действием проверки в каком-то внешнем цикле, прямо противоречит принципу сдвига влево, который пропагандирует McKinsey. Безопасность и соответствие требованиям должны быть неотъемлемой частью разработки программного обеспечения.
В своей книге Turn the Ship Around бывший командир американской подводной лодки Дэвид Маркет предлагает идею приглашения инспекции. Исторически сложилось так, что экипаж подводной лодки относился к инспекторам с подозрением и враждебностью. Марке перевернул это представление: однажды инспекторов весьма торжественно пригласили на борт, а затем попросили ознакомиться с полным списком проблем и предложений, пообещав устранить их все к следующей проверке.
Такой сдвиг в культуре привел к установлению более тесных и плодотворных отношений с инспекторами, и обе стороны в конце концов стали с нетерпением ждать этих проверок. Точно так же высокоэффективные команды приглашают экспертов по безопасности, соответствию требованиям, доступности, устойчивости и подобным кросс-функциональным факторам в качестве консультантов в свою деятельность по разработке, а не в качестве «блюстителей» в самом конце; и следят за тем, чтобы их архитектура, дизайн, даже выбор технологий отражали эти важные потребности бизнеса.
Совещания тоже не являются внешним циклом. Любая совместная работа — это совещание! Парное программирование — это постоянное совещание, в ходе которого которого пара коллег обсуждает различные идеи и подходы к дизайну, пробует некоторые из них и совместно создаёт решение; точно так же и групповое программирование. Опять же, «код-тест-сборка» — это лёгкая часть, а как насчёт решения? Вот для чего нужны короткие встречи или более структурированные глубокие погружения, и они должны происходить параллельно с другими видами деятельности по разработке, чтобы усовершнествовать процесс создания ценности.
Я понимаю, что необходимо регулярно проводить ревью и другие структурированные взаимодействия с внешними заинтересованными сторонами, чтобы продемонстрировать прогресс и получить обратную связь, но это не то, о чем говорится в вашей статье.
Управление тестовыми данными представляет собой «низкую ценность»?
Вы утверждаете, что управление тестовыми данными — это малозначимая деятельность. Помимо репутационного риска, связанного со случайным использованием данных реального клиента, во многих странах существуют юридические ограничения на использование данных клиента не по назначению.
Я работал в крупном интернет-провайдере, который однажды случайно отправил 16 000 активным абонентам письмо по электронной почте с текстом о том, что их доступ к широкополосной сети прекращается, используя реальные адреса в тестовом режиме. Как вы можете себе представить, на решение этой проблемы потребовалось немало времени и усилий, включая восстановление репутации.
Очистка данных и управление жизненным циклом тестовых данных должны быть постоянной и тщательно спланированной деятельностью. Я отношу это к той же категории, что и безопасность или соответствие требованиям, и «приглашаю проверку» аналогичным образом.
Работа с инфраструктурой представляет собой «низкую ценность»?
Оптимизация процессов — важнейшая функция высокоэффективных команд. Быстрый, автоматизированный конвейер выпуска — ключевое условие для частых релизов, а мастерство в определении, обеспечении и развитии инфраструктуры для поддержки этого является отличительным фактором.
Я наблюдал 10-кратное или даже 100-кратное увеличение операционных расходов на облачную инфраструктуру из-за неправильного выбора или отсутствия понимания в вопросах подготовки и управления инфраструктурой;, а точнее, 100-кратное сокращение операционных расходов благодаря тому, что мы сосредоточились на подготовке правильной инфраструктуры.
Похоже, ваша классификация «малоценной» работы основана на идее, что любая деятельность, не связанная с кодированием, имеет низкую ценность — что, очевидно, неверно.
Оценка талантов и способностей?
Я видел много попыток составить каталог навыков и способностей и сам проводил несколько таких исследований. Работа с общим списком навыков и возможностей не имеет смысла с точки зрения теории ограничений. Вместо этого нужно разрабатывать каталог навыков на основе организации клиента: его технического парка, его области, его ограничений.
Когда вы собираете команду, ключевые факторы успеха включают в себя знакомство с:
системами, над которыми ведётся работа,
бизнес-сферой и процессами, связанными с ней,
зависимостями upstream & downstream,
отношениями с заинтересованными сторонами и
основными технологиями.
Именно такие вещи мне нравится моделировать на карте возможностей: навыки, умения и знания, которые имеют непосредственное отношение к спросу, а не общие и расплывчатые.
Ваш пример, когда у клиента «больше разработчиков с начальными навыками, чем хотелось бы в идеале», к сожалению, не имеет смысла. Каждый разработчик имеет уникальный профиль навыков, будучи более опытным в одних областях и менее опытным в других. Если вы говорите о недостатке способностей в определённой области, это должно быть показано на конкретном примере. Если же вы придумываете некую линейную функцию, основанную на всех возможностях, то это не принесёт практической пользы.
Далее, как вы или они определяете «идеал» в данном случае, или это основано на общей кривой, такой как нормальное распределение? Это та же самая ошибка, которую мы обнаруживаем при ранжировании команд. В высокоэффективной команде все игроки находятся на одном конце кривой! Здесь нет нормального распределения и нет «слабого звена».
С точки зрения подбора ресурсов для команд, недостаток навыков в той или иной области не имеет значения, если этот недостаток не мешает команде добавиться результатов. Если же мешает, то, конечно, команда или организация должны стремиться устранить этот пробел;, но зачастую этого можно добиться, например, изменив подход или решение, а не пытаясь повысить квалификацию в той или иной области.
Слишком сложно для измерения?
Наконец, вы утверждаете, что разработка слишком сложна для измерения, с чем я не согласен. Применение редукционистского мышления и инструментария — это категориальная ошибка. «Лучшие» редукционистские инструменты просто удваивают усилия по выполнению неправильных действий с иллюзией тщательности.
Разработка программного обеспечения — это совместное, генеративное предприятие. Эффективность команды и, что более важно, её динамику с течением времени, легко можно измерить, используя теорию ограничений и метрики вроде времени выполнения и пропускной способности. Для более глубокого понимания этих показателей ознакомьтесь с работами Элияху Голдратта (Eliyahu Goldratt) и Дональда Райнерцена (Donald Reinertsen). Такая организация, как McKinsey, поддерживающая эти подходы, была бы большим подспорьем для отрасли.
Однако пытаться измерить индивидуальный вклад человека — всё равно что пытаться измерить индивидуальный вклад поршня в двигатель. Сам вопрос не имеет смысла.
Заключение
Ваше заключение сильное, но кажется запутанным. Мне нравится ваш призыв к действию — изучать основы и оценивать свои системы, хотя покрытие кода — это хорошо задокументированный отвлекающий манёвр, поскольку оно не является ни необходимым, ни достаточным условием для демонстрации качества. Вы предлагаете составить план, что вполне логично. Затем вы заключаете, что измерение производительности зависит от контекста, в то время как вся статья посвящена продвижению вашего инструментария для бесконтекстной оценки.
Дополнительные предложения
Ещё раз спасибо за то, что пригласили меня проанализировать вашу статью. Вы затронули важную и животрепещущую тему, и я надеюсь, что мой отзыв поможет вам подготовить более обоснованную статью. Я сторонник прозрачности и считаю полезным оценивать людей, чтобы помочь им в их собственном профессиональном развитии, а также на благо компании.
Однако вместо того, чтобы оценивать человека в отдельности, как это предлагается в вашей статье, я предлагаю целостный анализ низкой продуктивности. Если мы предполагаем, что нанимаем умных и мотивированных людей —, а если это не так, то нам нужно пересмотреть свою работу по подбору персонала, — то если кто-то из сотрудников оказывается «слабым» исполнителем, я воспринимаю это как сигнал о том, что мы подводим этого человека.
Что именно в системе работы — тип работы, инструментарий или поддержка, организационные ограничения, насколько конкретный человек подходит для этой работы или другие факторы — мешает этому сотруднику добиться успеха? По моему опыту, редко, хотя и такое бывает, когда человек просто «плохо работает». Более вероятно, что человек реагирует на контекст, в котором он находится, и если мы его уберём, то тот, кем мы его заменим, скорее всего, станет жертвой тех же ограничений.
Что касается личностного развития, то мне нравится обучать людей саморекламе, например, вести дневник достижений, в который они могут заглянуть во время performance review, и работать над своим личным брендом в организации. Я предпочитаю обратную связь в моменте и частые встречи 1–1, а не раз или два в год, что может ощущаться сотрудником как засада.
Если вы собираетесь оценивать отдельных людей в команде, то используйте обратную связь от коллег, чтобы понять, кто действительно вносит свой вклад. Я задаю такие вопросы, как «Кого вы больше всего хотите видеть в этой команде и почему?», или «Какой совет вы бы дали X, чтобы помочь ему развиваться?», или «Чему вы больше всего хотите научиться у Y?». Проницательный руководитель быстро увидит в этих отзывах коллег закономерности и тенденции, как положительные, так и отрицательные, и тогда можно будет принимать меры.
Думаю, многое здесь зависит от того, насколько мотивирован человек на проведение индивидуальной оценки. Если в основе оценки лежит «отсев плохих исполнителей», то это предполагает отказ от ответственности; идея о том, что в неудачном росте цветка виновата почва, а не климат. В этом контексте не имеет значения, какой инструмент мы используем для «оценки» людей, потому что мы явно решаем не ту проблему.
Помните новогодние каникулы 2021–22 года? Тогда библиотека Log4j подарила многим инженерам прекрасную возможность немного поработать в праздники.
И подобные сюрпризы — не редкость. Да и не сюрпризы вовсе, скорее, закономерность. Те, кто участвовал в крупных проектах, знают: везунчики ждут на Новый Год Деда Мороза, а к остальным приходит Дедлайн.
Как сохранить рассудок и здоровье в подобных ситуациях? И стоит ли вообще в них попадать? И что всё-таки делать, если «попал»? Поговорим об этом на открытом уроке «Дедлайн. Инструкция по выживанию» курса DevOps Lead.
