Привет, Хабр!

Часто тимлидов интерсует вопрс: как измерить продуктивность разработчиков так, чтобы это имело смысл? Часто можно наблюдать, как одни менеджеры пытаются оценивать работу команды количеством коммитов, другие — числом закрытых тасков, третьи искали «та самый единственная метрика», которая покажет продуктивность сразу всех и каждого. Такой метрики не существует, и погоня за ним часто приводит к курьёзным (а иногда и печальным) результатам. В этой статье я поделюсь свежим подходом к этой проблеме — фреймворком SPACE. Он предлагает смотреть на продуктивность инженеров комплексно, по нескольким измерениям сразу. Но для начала давайте разберёмся, почему вообще так сложно измерить эффективность разработки.

Почему измерять продуктивность разработчиков сложно?

Разработкой программного обеспечения занимаются люди — со всеми присущими человеку особенностями, настроениями и нюансами работы в команде. Попытки свести продуктивность такой творческой и интеллектуальной деятельности к одному числу неизбежно упускают что‑то важное. Неудивительно, что десятилетия исследований так и не дали простого ответа, как именно считать «полезность» работы программиста. Зато накопилось много мифов и заблуждений. Некоторые из них, возможно, знакомы и вам:

• Миф: продуктивность измеряется активностью. Казалось бы, чем больше коммитов, строк кода или pull request«ов сделал разработчик, тем он продуктивнее. На практике высокий объём активности может означать разное. Иногда это сигнал о переработках и попытках „закидать проблему кодом“ при плохом планировании или неэффективных инструментах. А может быть, наоборот, у команды отличные инструменты и процесс, позволяющие чаще вливать изменения. Одни лишь цифры активности не показывают качества работы, поэтому использовать их в отрыве от контекста опасно. Показатели типа количества коммитов или review выглядят объективно, но они не учитывают, например, парное программирование, коллективный брейншторм или помощь коллегам, которые тоже важны для дела.

• Миф: продуктивность — это сугубо индивидуальная эффективность. Многие сравнивают программистов со спортсменами: мол, у каждого свой рейтинг результативности. В реальности разработка — командная игра. Если инженер оптимизирует только свою личную скорость кодинга, не участвует в ревью, не помогает другим, вся команда от этого проигрывает. Значимый вклад включает и «невидимую» работу на благо команды: улучшение инфраструктуры, наставничество, обмен знаниями, участие в поддержке пользователей и т. д.

• Миф: есть единый «главный» показатель продуктивности. Часто хочется получить one metric to rule them all, например сплавить все показатели в один индекс и по нему сравнивать разработчиков или команды. Такой подход не работает — слишком уж многогранна деятельность инженеров. Количество строк кода, скорость закрытия задач, велосити, количество багов — каждое число показывает лишь одну сторону. Универсального «очкового счета», справедливого для разных команд и проектов, не получается. Более того, на продуктивность сильно влияет контекст: тип продукта, процессы, культура, доменная область. Нельзя напрямую сравнить, скажем, команду, пилящую UI в стартапе, и команду, поддерживающую банковский бэкенд — единый балл ввёл бы в заблуждение.

• Миф: метрики нужны только менеджерам, разработчикам они бесполезны. Пожалуй, такой скепсис у девелоперов появился не на пустом месте — действительно, плохо подобранные метрики часто идут во вред. Но правильно измеряя свою работу, и сами инженеры могут получить пользу. Например, отслеживая, сколько времени уходит на отвлечения vs. сконцентрированную работу, разработчик может лучше организовать свой день. Исследования показывают, что ощущение высокой продуктивности тесно связано с удовлетворённостью работой и даже счастьем разработчика.

Разобравшись с тем, чем продуктивность не является, перейдём к позитивной повестке. Группа исследователей из Microsoft и GitHub, устав наблюдать за злоупотреблением метриками, предложила практичный многомерный подход к этой теме. В 2021 году они опубликовали работу, где описали пять ключевых измерений продуктивности разработчиков, вместе образующих говорящую аббревиатуру SPACE (от слов Satisfaction, Performance, Activity, Communication, Efficiency). Рассмотрим каждый из компонентов SPACE подробнее.

SPACE: пять граней продуктивности разработчиков

SPACE — это акроним, в котором зашифрованы пять разных сторон (dimension) продуктивности в разработке ПО. Идея проста: чтобы по‑настоящему понять, насколько эффективно работает ваш инженер или команда, нужно смотреть сразу на несколько граней. Если мы игнорируем какие‑то из них, рискуем принять неверные решения. Расшифруем SPACE:

S – Satisfaction & Well-Being (Удовлетворённость и благополучие)

Это то, насколько разработчики довольны своей работой и как они себя чувствуют. На первый взгляд может показаться, что настроение — вещь второстепенная. Но исследования и опыт подсказывают обратное: удовлетворённость тесно переплетена с продуктивностью. Если программист ощущает себя «в ударе», он пишет код с энтузиазмом. Если же работа его удручает, то ни о какой высокой эффективности речь не идёт — человек может банально выгореть.

Важно измерять удовлетворённость, чтобы видеть проблемы до того, как они выльются в спад производительности или уход ценного сотрудника. Например, в пандемию многие команды внезапно перешли на удалёнку. По метрикам активности всё выглядело даже позитивно — некоторые разработчики начали коммитить больше, pull request«ы закрывались быстрее. Но опросы показали, что часть людей еле справляются — им тяжело психологически. Рост коммитов маскировал накопление усталости. Когда это выяснилось, отдельные компании даже начали вводить дополнительные оплачиваемые „дни для перезагрузки“, чтобы команда могла перевести дух.

Как же оценить удовлетворённость? В арсенале в основном опросы и анкеты. В них можно спрашивать, доволен ли разработчик своими задачами, командой, ощущает ли смысл в работе, хватает ли ему инструментов для эффективной работы (так называемая developer efficacy — ощущение, что «мне дают всё, что нужно, чтобы кодить продуктивно»), нет ли симптомов выгорания. Резкое снижение позитивных оценок — тревожный сигнал: возможно, люди недовольны новым процессом, или перегружены, или конфликт в коллективе. В любом случае, зная об этом, тимлид может вовремя вмешаться — перераспределить нагрузку, улучшить коммуникации или поднять вопрос ресурсов. Помните, что счастливый разработчик — продуктивный разработчик, а недовольный рано или поздно замедлит работу всей команды.

P – Performance (Результативность работы)

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

Проблема в том, что вклад отдельного разработчика трудно изолировать. Софт — плод совместных усилий, и результат зависит не только от каждого в отдельности, но и от взаимодействия. Кроме того, разные программисты могут делать задачи разной значимости. Один пилит ключевую фичу, другой — второстепенный сервис. Это не значит, что второй менее продуктивен как инженер — просто влияние его работы на бизнес не такое заметное. Поэтому performance чаще оценивают на уровне команды или продукта.

Какие метрики показывают performance? Например, качество: число багов, инцидентов, откатов релизов. Если команда плодит баги — явно есть проблемы с продуктивностью (может, спешат в ущерб качеству). Ещё показатель — польза для пользователей: удовлетворённость клиентов, рост числа активных юзеров, удержание аудитории, снижение затрат. Конечно, на эти бизнес‑метрики влияет не только код, но и маркетинг, и прочее. Однако в разрезе команды можно попытаться связать работу с такими impact‑показателями. Например, фича, написанная разработчиком, увеличила конверсию на сайте — безусловно, его работа была продуктивной в смысле пользы продукту.

Важно не путать результативность с активностью. Разработчик может выдать тонны кода, которые не решают проблему пользователя или даже вредят стабильности — тогда высокая активность, но низкая результативность. И наоборот, кто‑то делает меньше коммитов, но они приходятся на сложные участки, повышают отказоустойчивость системы — результативность высокая, хоть git‑статистика скромная. В SPACE фреймворке предлагается смотреть на качество, ценность, влияние работы, а не только на объём выполненных задач.

A – Activity (Активность)

Активность — это все те измеряемые действия, которые выполняют разработчики в ходе работы. Сюда относится практически всё, что фиксируется инструментами: коммиты, открытые pull request«ы, пройденные тесты, развернутые сборки, комментарии в код‑ревью, написанные дизайны и документы, проведённые созвоны… Перечислять можно долго. Обычно, говоря про метрики активности, имеют в виду количественные показатели процессов разработки: сколько задач закрыто в спринте, сколько строк кода добавлено за неделю, как часто деплоим на прод, сколько инцидентов решили за месяц и т. д.

Как мы уже обсуждали, показатели активности очень заманчивы, потому что их легко собрать и визуализировать. Инженеры — люди рациональные, и видеть конкретные цифры прогресса приятно. Эти метрики действительно полезны, но только как часть общей картины. Они могут подсказать, где узкие места: допустим, сборка проходит слишком долго или пулл‑реквесты висят неотревьюенными по несколько дней. Однако по одной лишь активности нельзя делать выводы о продуктивности. Высокая активность может скрывать проблемы (например, зачем‑то делается куча лишних изменений), а низкая — не всегда плохо (может, команда в это время занималась обдумыванием архитектуры или обучением нового сотрудника). Кроме того, упор на количественные показатели стимулирует «играть в числа», вместо того чтобы работать умнее. Если вознаграждать за количество коммитов — получите много коммитов, но их ценность будет сомнительной.

Тем не менее, отслеживать активность полезно. Просто применять эти данные стоит аккуратно. Хороший подход — смотреть динамику: рост или падение тех или иных показателей, корреляцию с изменениями в процессах. Например, вы внедрили новую систему CI — и через месяц видите, что частота деплоя выросла с раз в неделю до нескольких раз в неделю. Отлично, команда стала работать быстрее! Или другой пример: один разработчик вдруг начал коммитить значительно меньше. Возможно, его что‑то блокирует или он выгорел — повод пообщаться. Таким образом, метрики активности могут служить тригером, подсказкой: куда взглянуть внимательнее. Но ни в коем случае не окончательным вердиктом в духе «Вася сделал 50 коммитов, Петя 30, значит Вася продуктивнее» — такой подход дорога в никуда.

C – Communication & Collaboration (Коммуникация и сотрудничество)

Разработка — это коллективный труд, поэтому продуктивность во многом зависит от того, как люди взаимодействуют. C в SPACE обращает внимание на командную динамику: насколько эффективно инженеры обмениваются информацией, помогают друг другу, работают вместе над задачами. Бывает, что умнейшие программисты по отдельности в сумме дают посредственную команду — просто потому, что не общаются, каждый сидит в своём уголке. А бывает наоборот: средние специалисты, но благодаря слаженному взаимодействию они показывают чудеса скорости и качества.

Какие здесь метрики? Они скорее косвенные, но интересные. Например, время code review: сколько проходит с момента, когда разработчик создал PR, до момента, когда коллеги его отревьюили и приняли. Если ревью ждут по несколько дней — коммуникация барахлит, разработчики блокируют друг друга. Сократили это время — молодцы, команда стала более расторопной. Другой пример: показатель «bus factor» (или коэффициент автобуса) — сколько человек владеют знанием по каждой части системы. Если по модулю A компетентен только один инженер, команда уязвима: заболеет он — встанут все. Поэтому обмен знаниями, документация, парное программирование повышают устойчивость команды и, как ни странно, связаны с продуктивностью тоже (в долгосроке точно).

Можно измерять и вовлечённость в команду. Скажем, сколько людей участвует в решении инцидентов — если все наваливаются вместе или хотя бы в курсе, это лучше, чем когда только один дежурный молча тушит пожар. Или время адаптации (onboarding) новичков — метрика того, насколько команда открыта и помогает новым коллегам влиться.

Конечно, не всё поддаётся формализации. Часто самое ценное взаимодействие — неформальное и невидимое инструментами. Помочь коллеге найти баг, провести митап внутри отдела, сделать обзор новой технологии для команды — такие вещи сложно посчитать, но они влияют на общую успешность. Поэтому при оценке collaboration аспекта нередко используют опросники: например, спрашивают, чувствуют ли разработчики, что получают поддержку от команды, достаточно ли у них информации о том, кто чем занимается (прозрачность), комфортно ли обращаться за помощью и т. д. Если этого нет, люди начинают работать в изоляции, дублировать усилия, медленно решать проблемы.

Отдельно отмечу такой момент: баланс между индивидуальной работой и сотрудничеством. Иногда, стремясь к командности, можно завалить людей совещаниями и групповыми активностями, лишив их личного времени на сконцентрированную работу. С другой стороны, полный lack of общения ведёт к «силосам» и снижению общей эффективности. Нужно искать золотую середину, и метрики SPACE помогают увидеть перекосы. Например, если Efficiency (эффективность) провисает — может, слишком много митингов перебивает flow разработчиков. А если Activity низкая и «стоит в очереди» — возможно, люди боятся спрашивать помощь, и задачи тормозятся из‑за отсутствия общения.

E – Efficiency & Flow (Эффективность и состояние потока)

Последняя буква SPACE касается того, насколько эффективно протекает процесс разработки и насколько разработчики могут работать в состоянии «потока» (flow). Здесь есть два уровня: индивидуальный (личная эффективность) и системный (эффективность процесса, команды).

На индивидуальном уровне речь о том самом ощущении, когда вы сели, погрузились в задачу и за пару часов сделали больше, чем за весь вчерашний день, когда вас отвлекали. Давно подмечено: программисту нужна фаза разгона, чтобы войти в кoding mode, и каждый контекст свитч или звонок разрушает это состояние. Поэтому одним из показателей индивидуальной продуктивности служит непрерывное время фокусной работы — сколько часов в день разработчику удаётся посвятить чистому созданию ценности (код, дизайн, тесты), без встреч, переписок и отвлечений. Многие инструментальные метрики пытаются это косвенно отразить: например, время в IDE (редакторе кода) vs. время в почте/мессенджере, или число больших «коммитов‑подвигов» vs. мелких фиксов. Но опять же, цифры — лишь приближение. Часто проще спросить самих ребят: «Удается ли вам выделять достаточно блоков времени на глубокую работу? Не мешают ли вам постоянно дёргаться?» Ответы дадут представление, есть ли проблемы с рабочим процессом (например, слишком много встреч или смежные команды постоянно отвлекают запросами).

На уровне команды и процесса efficiency означает, насколько слаженно и быстро фича проходит путь от идеи до выката в прод. Здесь на помощь приходят классические DevOps‑метрики (DORA): частота деплоя, время от коммита до релиза, среднее время восстановления после инцидента и т. п. Если фичи выходят раз в квартал, а баги чинятся неделями, какая уж тут продуктивность — пользователи вечно ждут результат работы. Цель — устранить «трение» в процессе разработки: автоматизировать ручные этапы, параллелизовать работу, убрать лишние согласования. Метрик тут множество: количество handoff«ов (скольким людям или командам передаётся задача на пути к продакшену), среднее время Code Review, время сборки, длина очереди задач в бэклоге, и даже „процент повторного открытия баг‑репортов“ (когда фиксы делают не до конца и баг возвращается). Все они про одно — находит ли работа „поток“, движется ли непрерывно или где‑то застаивается.

Однако важно смотреть в комплексе. Например, можно сократить время на тестирование и сильно повысить скорость релизов — но упадёт качество (увеличится число багов, то есть пострадает Performance измерение). Или наоборот, бросить все силы на рефакторинг для повышения качества — а новых фич не выпускать (активность и impact упадут). SPACE как раз заставляет удерживать баланс. Efficiency и Flow нельзя максимизировать в отрыве от других показателей, иначе рискуем нарушить хрупкое равновесие. Задача тимлида — выстроить процесс так, чтобы команда двигалась быстро и качественно, а люди при этом не были на грани выгорания.

После этого экскурса возникает логичный вопрос: как же применить все эти метрики на практике, чтобы оценить и улучшить работу команды? Ответ: постепенно и взвешенно.

Как применять SPACE

1. Измеряйте по нескольким измерениям сразу. Одного числа недостаточно — мы это уяснили. Оптимально взять минимум 3 разных метрики из разных категорий SPACE. Например, вы уже считаете число коммитов (активность) — добавьте к дэшборду, скажем, результаты опроса по удовлетворённости (S) и среднее время code review ©. Такой набор даст намного более объёмную картину, чем любой один показатель. Если где‑то метрики противоречат друг другу — отлично, это и называется «напряжение метрик», которое не даст увлечься в одну сторону. Допустим, коммитов стало меньше, зато удовлетворённость выросла — возможно, команда стала тщательнее продумывать решения вместо гонки за кодом, и люди чувствуют себя лучше. Или наоборот, время код‑ревью резко выросло (ревью затягиваются) и одновременно люди в опросе жалуются на частые отвлечения — вот вам явный фокус для улучшения процесса.

2. Не забывайте про субъективные показатели. Как ни крути, ощущения самих разработчиков — ценный источник правды. Инструменты могут не всё поймать. К тому же, порой цифры лгут меньше, чем люди (точнее, наоборот — люди могут дать контекст, которого нет в цифрах). Поэтому добавьте в свой measurement mix опросы или хотя бы регулярные командные ретроспективы с вопросом «что мешает работать эффективнее?». Бывало, по отчетам всё гладко, а спросишь команду — и выясняется, что они тратят кучу времени на сборку проекта или рутину, просто терпели молча. Перцептивные (чувствительные) метрики позволяют такое всплыть. Кстати, многие команды сейчас делают анонимные ежемесячные опросы настроения — и коррелируют их результаты с объективными показателями.

3. Комбинируйте метрики осознанно, помня про побочные эффекты. Каждый показатель стимулирует людей менять поведение. Вы объявили, что считаете количество выкатанных фич — будьте уверены, разработчики начнут дробить фичи помельче, лишь бы увеличить счётчик. Любую метрику можно «надуть» в ущерб делу — это закон жизни. Поэтому, во‑первых, не злоупотребляйте «соревнованиями» по метрикам. Метрики нужны для вас, а не вы для метрик. Лучше использовать их как индикаторы проблем, а не KPI для премий. Во‑вторых, выбирайте сбалансированный набор, отражающий разные приоритеты.

4. Меньше — лучше. Хотя мы и говорим брать несколько метрик, не увлекайтесь их количеством. Если сделать дэшборд из 20 графиков, команда утонет в данных и потеряет фокус. Обычно достаточно выбрать 3–5 ключевых метрик. Например: удовлетворённость команды (S), скорость доставки кода в прод (E), процент успешных релизов без отката (P), среднее время код‑ревью © и количество коммитов в месяц (A). Уже этот набор покроет основные грани и даст пищу для действий.

5. Следите за тенденциями, а не абсолютными цифрами. Полезнее всего смотреть в динамике — прогресс или регресс. Например, вы начали инициативу по улучшению документации — значит, ожидаете, что время онбординга новичков сократится. Мониторьте это. Или решили перевести команду на 4-дневную рабочую неделю (эх, мечты) — интересно посмотреть, как поменяется удовлетворённость и продуктивность через пару месяцев. Экспериментируйте и измеряйте. SPACE хорош тем, что покажет влияние изменений сразу по нескольким углам зрения. И если где‑то начался перекос, вы это заметите. Растёт активность, но падает удовлетворённость? Тормозите, люди перегружаются. Ускорилась разработка, но посыпались баги? Нужно подтянуть качество, может, добавить тесты. Метрики — ваш компас, но рулить кораблём всё равно вам.

В заключение: зачем всё это нужно тимлидам, именно сейчас. За последние годы разработка изменилась: распределённые команды, удалёнка, ускорение релизов, DevOps, AI в конце концов — всё это усложняет пейзаж. Старые примитивные подходы к оценке труда программистов не работают, а попытки применять заводские KPI к айтишникам вызывают только отторжение. Фреймворк SPACE предлагает современный и гибкий взгляд на продуктивность инженеров. Он учитывает и человеческое начало (satisfaction), и командную динамику (communication), и технические результаты (performance), и процесс (efficiency), и усердие (activity). Конечно, внедрить такое измерение — вызов. Нужно мудро подобрать метрики под свой контекст, не перегнуть палку и не утонуть в данных. Но награда стоит того: вы начнёте лучше понимать свою команду и факторы успеха. Вместо ощущений «что‑то мы буксуем последнее время» у вас будут конкретные сигналы, где проблема — в настроении ли команды, в качестве ли продукта или в процессе разработки.

Возможно, вы увидите то, что ранее ускользало от внимания. Если у вас уже есть опыт применения SPACE или схожих подходов — поделитесь в комментариях, будет интересно узнать практические кейсы. А у меня на этом всё. Спасибо, что дочитали до конца! Надеюсь, эта статья помогла структурировать мысли о продуктивности, и желаю вам и вашим командам оставаться эффективными, но при этом счастливыми — ведь одно без другого мало чего стоит.

Чтобы подход SPACE действительно работал, важно не только измерять метрики, но и развивать команду в тех областях, где выявлены пробелы. Для этого подойдут корпоративные услуги OTUS. Они позволяют системно повышать уровень специалистов: бесплатные тесты и открытые уроки помогают объективно оценить текущие знания сотрудников, а затем выстроить программу обучения на основе реальных данных. Такой подход делает развитие команды логичным продолжением работы с метриками, а не отвлечённым процессом.