Последние два с половиной года я руководил различными командами и анализировал продуктивность и производительность товарищей по команде с разным опытом.

McKinsey опубликовала отчет и изложила некоторые показатели производительности, которые помогут построить основу для технологических компаний.

Как только я прочитал этот отчет, первый вопрос, который я задал себе, был: измеряю ли я продуктивность членов моей команды? Если да, то использую ли я один общий подход для всех? Ответ - нет.

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

Да, каждая компания нуждается в лучших талантах и ​​хочет заменить наименее продуктивных инженеров наиболее продуктивными. Однако параметры производительности одного разработчика совершенно отличаются от показателей другого.

Невозможно применить одну формулу, которая подойдет всем, и ожидать точных результатов. Это будет разрушительно.

Допустим, есть три разработчика: A, B, C и D, которые работают в команде и прилагают 100% усилий.

Разработчик А работает над новыми функциями и регулярно их предоставляет.

Разработчик Б сокращает технический долг, оптимизируя код для обеспечения масштабируемости и открывая путь для быстрой разработки новых функций.

Разработчик C большую часть времени блокируется из-за сторонних зависимостей и не может быть доставлен.

Разработчик D работает с совершенно новым стеком, темпы разработки медленные, но все идет в соответствии с договорными ожиданиями.

Кто получит больше признания и будет считаться более продуктивным на типичных совещаниях высшего руководства? Означает ли это по каким-либо стандартам, что один из них менее продуктивен, чем другие? Человек, устраняющий ошибки или сокращающий технологический долг, может показаться менее продуктивным, чем человек, предоставляющий функции в типичной технологической компании.

Краткое изложение отчета McKinsey

McKinsey считает, что у них есть решение для измерения продуктивности разработчика.

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

Учитывая сложность и необходимость сотрудничества при разработке программного обеспечения, в эссе признаются трудности с оценкой производительности разработчиков.

Инновационная методика статьи предполагает оценку производства на трёх уровнях: системе, команде и человеке, с использованием метрик DORA и SPACE, а также метрик, ориентированных на возможности.

В нем представлены новые показатели, включая частоту развертывания, время выполнения изменений и анализ вклада, для оценки производительности и поиска областей для улучшения.

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

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

Анализ с точки зрения разработчика и ведущего инженера

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

1. Неинженерный человек, оценивающий производительность разработчиков и влияющий на решения.

Вот здесь и начинается проблема.

Это просто кнопка или API, подключенный к базе данных.

Неспециалисту это может показаться просто функцией, но концепции технологического долга, архитектурных решений и реализации функций наивны.

Вопрос в том, что когда технический директор возглавляет техническую сторону, не должен ли он командовать, увольнять и нанимать разработчиков в зависимости от их производительности?

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

Изучите основы. Всем руководителям высшего звена, не являющимся инженерами или долгое время занимавшим руководящие должности, потребуется введение в процесс разработки программного обеспечения и о том, как он происходит. развивается.

Это приятное заявление, но не все технологические компании создают один и тот же продукт. НИОКР, архитектурные решения и накладные расходы различаются. Жизненный цикл разработчика и программного обеспечения в финтех-стартапе отличается от типичного SAAS. Итак, вопрос в том, готовы ли менеджеры высшего звена учиться на примере своего продукта?

2. Все внимание на кодировании

Как с точки зрения производительности, так и с точки зрения личного опыта желательно максимально увеличить количество времени, которое разработчики проводят во внутреннем цикле: создание продуктов напрямую создает ценность и — это то, чем с радостью занимается большинство разработчиков.

В документе говорится, что чем больше кода пишет разработчик, тем более продуктивным он является. Ирония в том, что оно косвенно настаивает на формировании в организациях мышления программистов.

Нет упоминания о том, насколько различные аспекты разработки программного обеспечения, такие как построение проекта системы, принятие архитектурных решений и обсуждение масштабируемости, влияют на ход разработки продукта.

3. Внешний цикл полностью обобщен для всех разработчиков.

Отсутствие разработки платформ и стандартизации DevOps будет препятствовать прогрессу разработки и заставит разработчиков меньше концентрироваться на своей работе.

Имеет смысл разблокировать разработчиков для конвейеров и развертываний CI/CD, но исключение совещаний, безопасности и соблюдения требований из деятельности разработчика — это скорее обобщение.

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

Разработчик, работающий в сфере финансовых технологий и банковского дела, заботится о безопасности и соблюдении требований. Если развитие развивает продукт, то, очевидно, в игру вступают эти факторы. Кто тогда будет реализовывать эти функции?

4. Никакого упоминания об автоматизированном и ручном тестировании или инженерах DevOps.

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

Разработчики — не единственные, кто создает продукт, и им необходимо работать продуктивно. Команда контроля качества и DevOps играют равные роли. Здесь не определяется показатель для измерения их производительности.

Для ручного контроля качества и тех, кто занимается автоматизацией, нужны разные критерии, как и для DevOpsers.

5. Индекс скорости развития

Фактически, DV повышает эффективность разработчика и всего цикла разработки программного обеспечения. Производительность разработчика упадет до нуля, если он застрянет в CI/CD-конвейерах, ручном модульном тестировании, утомительных стратегиях продвижения кода и т. д.

6. Игнорирование вклада разработчиков, не связанного с кодированием

Например, одна компания обнаружила, что ее самые талантливые разработчики тратят слишком много времени на деятельность, не связанную с программированием, такую ​​​​как сеансы проектирования или управление взаимозависимостями между командами. В ответ компания изменила свою операционную модель и уточнила роли и обязанности, чтобы дать возможность самым ценным разработчикам заниматься тем, что они делают лучше всего: писать код.

Здесь компания ошиблась, и эта модель нежизнеспособна.

Можно предположить, что самые талантливые разработчики должны знать все тонкости продукта и внутренние зависимости, пересекающиеся между командами. Кто должен руководить, создавать или оценивать проекты и проекты систем? Наняты ли на эти конкретные должности эти талантливые разработчики или другие люди? Были ли эти разработчики полностью превращены в ботов-кодировщиков?

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

Создание для этого отдельной роли создает только разногласия, а не хороший код и продукты.

7. Структура не учитывает контекстуальность

Помните, что измерение продуктивности зависит от контекста. Смысл состоит в том, чтобы взглянуть на всю систему и понять, как она может работать лучше, улучшая среду разработки на уровне системы, команды или отдельного человека.

Это позитивный момент в отчете, и это правда.

На моей работе мой менеджер оценивает мою продуктивность и производительность в другом контексте, чем я оцениваю членов моей команды, работающих с другим набором технологий.

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

Некоторым менеджерам высшего звена разработчик может показаться непродуктивным, поскольку реализация функции задерживается, но причина не в проблеме производительности.

Аналогичным образом, если команда или разработчик недооценивает ETA и нет блокировщиков, они не смогут защититься от задержек, и проблемы производительности и производительности окажутся в центре внимания.

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

8. Влияние разработчика на команду больше, чем написание кода

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

Чем больше ваше влияние, тем более продуктивным и исключительным вас будут считать.

Краткое содержание

Это очень приятный отчет, но он имеет некоторые основные недостатки. Каждый менеджер хочет знать уровень производительности своей команды и способы его повышения. Но его нельзя обобщать и применять во всех организациях. У каждого разработчика или команды разные задачи и обстоятельства. Точно так же у каждого разработчика есть свои сильные и слабые стороны, которые влияют на создаваемый продукт. Некоторые умеют разблокировать коллег по команде и создавать решения, в то время как другие пишут исключительный и оптимизированный код. Те, кто внедрит эту структуру, создадут больше программистов, чем инженеров-программистов, создающих решения.

Спасибо за прочтение.

Давайте соединимся в LinkedIn.