Оценка эффективности и KPI-программиста — как это измерить?

То, что мы можем легко получить, это данные, а не информация. Данные это просто набор цифр. Информация, с другой стороны, требует человеческой обработки, чтобы её понять

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

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

Данная статья основана на публикации Medium.

Святой Грааль

Поиск хорошего способа оценки эффективности для программистов всегда был своего рода «святым Граалем». Многие пытались, немногие преуспели. И причина этого гораздо более очевидна в наши дни, чем в то время, когда разработка программного обеспечения была молодой отраслью.

Вот соответствующая цитата от легенды джаза Майлза Дэвиса о том, что делает великолепную джазовую мелодию:

«Это не те ноты, которые вы играете, а ноты, которые вы не играете» — Майлз Дэвис.

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

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

Программирование это искусство

Возможно, это слишком абстрактное описание, потому следует рассмотреть каким образом это проявляется:

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

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

Короче говоря, измерение «объема работы» для оценки разработчиков, просто не имеет смысла, поскольку объем в любой материальной форме вряд ли соотносится с усилием и качеством.

Поиск альтернативы

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

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

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

Будущее измерения параметров кода

Такие компании, как GitPrime и Waydev, предлагают новые показатели на основе Git, которые могут значительно лучше демонстрировать, как программисты справляются с разработкой программного обеспечения.
Это достигается за счёт нескольких метрик, например:

• Отток кода — означает объем кода, который был изменен менее, чем за 30 дней с момента его первого коммита. Этот параметр указывает на то, что может быть выполнено большое количество работы, которая в конечном итоге не окажет влияния на результат важный на бизнес-уровне.
• Объем рецензирования кода (code review), в духе сотрудничества и коллективного обучения, является мерой того, какое количество кода проверяет каждый разработчик.
• Влияние, это сложный параметр не до конца понятный большинству. Согласно документации, этот параметр должен соотноситься с «когнитивной нагрузкой», что означает, сколько времени и сил, предположительно, ушло на создание определенного коммита, независимо от того, является ли это редактированием, добавлением или удалением.

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

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