Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Как измерить программиста

[Об авторе: Руслан Дмитракович — разработчик ПО и предприниматель, в ИТ-индустрии с 1994 года. Пионер интернет-рекламы в Украине: основатель Украинской баннерной сети, рекламного агенства «Интернет-эксперт». Создатель проекта Code X-ray — повышение эффективности работы команд разработчиков на основании статического анализа кода]

Решил свой рост узнать удав!
И в этом он, конечно, прав.
Ведь это важно очень!
Возможно, он длиннее всех!
Во много раз длиннее всех!
«38 попугаев» Г. Остер


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

Иллюстрация Ульяны Морозовой

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

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

Не все программисты «одинаково полезны»

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

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

В работе программиста не все так однозначно. Что является «продукцией» в данном случае? Например, программист Николай, решая задачу, будет, не вставая со стула, стучать по клавиатуре три дня и создаст множество кода.

Программист Василий, обдумывая решение, будет гулять по кухне, общаться с коллегами и бездельничать другими самыми разными способами. Однако за те же три дня выдаст решение, которое по объёму кода в несколько раз меньше, понятнее его коллегам и к тому же работает быстрее. И в том и другом случае задача решена, результат получен. Можно ли сравнить Василия и Николая? Например, чтобы выбрать, кого из них сделать руководителем группы.

Но что, если мы захотим подойти к вопросу объективно? Какие показатели будем измерять? Объем написанного кода? Количество решённых задач? Попытки применять такие метрики для оценивания работника ни к чему хорошему не приводили. Зная, какой именно показатель измеряется, специалист начинает им манипулировать: писать лишний код или разбивать задачи на более мелкие.

И всё-таки любой, кто сталкивался с разработкой, знает, что не все программисты «одинаково полезны». Эта разница может быть ощутима. В реальности чаще всего такая оценка делается интуитивно. Интуиция — это часть опыта человека, соответственно, у менеджера проекта и техлида интуиция будет давать разные результаты. Менеджер проголосует за пыхтящего Николая, техлид — за Василия, решившего задачу, с его точки зрения, лучше. Но кто же из них прав?

Оцениваем качество работы

Оценить действия ближнего своего люди пытаются с давних времён. Решая эту проблему, индусы придумали понятие «карма»: последствия твоих действий влияют на твоё будущее. Та же идея применима к программисту, работающему над проектом. И в данном случае кармой является та сложность, которую программист привносит в проект. За это он и его коллеги будут расплачиваться в последующих итерациях потерянным временем и ошибками.

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

Понятия «легаси» и «говнокод» прочно вошли в лексикон разработчиков ПО. Надо понимать, что говнокодом принято называть код, несущий избыточную когнитивную нагрузку. Чем меньше эта нагрузка, тем быстрее разбирается программист с кодом и тем меньше ошибается. Почему так происходит, можно почитать, например, у Даниэла Канемана в книге «Думай медленно, решай быстро» или у Дэвида Рока «Мозг. Инструкция по применению».

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

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

Один и тот же функционал может быть реализован множеством разных способов. Как это будет сделано, зависит именно от того, кто будет писать код. При анализе большого объёма кода оказывается, что одни программисты пишут код сложнее, чем другие. А именно — для кода, написанного одним программистом, усреднённые метрики сложности будут больше, чем для кода, написанного другим.

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

Пример

Наконец удав почувствовал, что его дёргают за хвост!
«Ага! — подумал удав. — Начали измерять!»


Чтобы не быть голословным и показать, как это работает, рассмотрим реальный проект примерно на полмиллиона строк кода. Возьмём трёх программистов, сделавших в проект значительный вклад.

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

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

Для построения графиков использовались цикломатическая сложность, средний размер метода (в строчках кода), композитные метрики: weighted methods per class и сопровождаемость кода (maintainability).

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

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

Измеряем производительность

А как насчёт производительности? Есть мнение, что измерить ее в масштабах всего бизнеса невозможно, и с этим я спорить и не буду. Однако если оперировать не деньгами, полученными от работы ПО, а артефактами внутри программного проекта, то кое-что измерить можно. Корреляция между объёмом кода (строк, классов, методов и т. д.), написанного программистом, и функциональностью программы есть. Однако значимость кода в проекте не одинакова.

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

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

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

Однако как определить формально, какой код имеет больший вес? В своё время похожую задачу решали создатели Google по отношению к документам в интернете. И если мы можем использовать Page Rank для определения важности документа, то почему бы не применить его к коду?

Итак, вкладом программиста в проект я буду называть объем написанного кода, умноженный на его PR. Следует понимать, что считать его также можно по-разному, и дело не в абсолютной точности, а в возможности сравнения.

Пример

И снова посмотрим, как это выглядит на примере нашего проекта.

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

Диаграмма ниже отображает суммарный вклад разработчиков в проект.

Те же данные в виде таблицы:

РазработчикиСтрок кодаСтрок кода, %ПакетовВклад, %
DEV-150К9366.94
DEV-236К7288.37
DEV-323К4156.2

Больше всего пишет DEV-1 (50 тысяч строк, или 9% кода проекта), но его средняя ценность почти в два (!) раза меньше, чем у DEV-3. Если учесть, что этот код ещё и более сложный, то можно понять, откуда берётся легаси — чем сложнее код и чем его больше, тем тяжелее его сопровождать. В какой-то момент может оказаться, что лучше такой код вообще не трогать...

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

Как видим, команды более-менее сбалансированы, вклад в проект у них примерно одинаковый.

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

Ну, и любопытный вывод для команды 2. Очень похоже, что техлид в ней действует по принципу «Хочешь сделать хорошо — сделай это сам»...

Выводы

— Теперь, — воскликнул удав, — когда приедет моя бабушка и скажет:
Ну, внучок, ты, кажется, вырос!" — я ей отвечу: «Да, бабушка, я вырос».
И я скажу ей свой рост в попугаях!


Если вы посмотрите полюбившийся многим «Чистый код» Боба Мартина, вы не найдёте чёткого определения, что этот самый «чистый код» собой представляет. Это свидетельствует о том, что у большинства есть только интуитивное представление, «что такое хорошо, и что такое плохо» по отношению к коду. В ходе данной работы я попытался объяснить это показателями, которые можно измерить.

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

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Шок! Эффективный менеджер спустя 25 лет работы в индустрии узнал, что эффективность программиста измеряется не только в строчках кода, но и в их полезности!
Сколько еще лет понадобится, чтобы узнать, что коммит в котором код удаляется может быть в разы полезнее, чем тот в котором он добавляется? Или что техлид, который может писать 10% кода от рядового синьйора, тоже полезен?

Пожалуйста, прекратите оценивать эффективность отдельных программистов. Оценивайте эффективность команд.

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

Например:

И если мы можем использовать Page Rank для определения важности документа, то почему бы не применить его к коду?
Итак, вкладом программиста в проект я буду называть объем написанного кода, умноженный на его PR.

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

Однажды фиксил багу в старом легаси: несколько сервисов, облако, сервисы написаны на 2-х языках. Кейс попался очень сложный, потратил 1,5 недели, фикс в 2 строчки, как это оценивать?)

Петро розібрався що там були за тормозні запити в базу, а Василь бекпортнув дрова для залізяки з останнього кернела. Михайло за тиждень розв’язав трішки отой шмат легасі, який всі боялися чіпати, а Микола, доки всі займались фігнею, прилаштував нарешті конопочку, в результаті чого замовник досі в екстазі. Як їх поміряти, якщо без кожного з них проект стане? Всі ці метрики, як і купа інших скрамів, добре працюють тільки на однотипних проектах з однотипними програмістами.

121 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

В старі добрі часи на британських урядових проєктах я познайомився з принципом Manage By Exception.

Скажіть будь ласка, у вас є старий добрий Project Initiation Document, Project Charter чи його аналоги?

Коментар порушує правила спільноти і видалений модераторами.

Программист Dev-1 пишет сложный код потому что... не умеет в clean code.

Статья четко показывает что качество кода автоматически измерить нельзя. Всегда нужно думать головой. Если код пишут всего трое — достаточно посмотреть историю коммитов. В идеале — следить за ней постоянно. Что должен делать условный техлид. Если вы не доверяете своему техлиду — найдите такого какому будете доверять (или сами увольтесь — trust is a two-way street).

Избавиться от субъективизма путем автоматизации не удасться — субъективизм просто перекочует к автору метрик, и все важные нюансы потеряются в примитивизме метрик.

Коментар порушує правила спільноти і видалений модераторами.

Петро розібрався що там були за тормозні запити в базу, а Василь бекпортнув дрова для залізяки з останнього кернела. Михайло за тиждень розв’язав трішки отой шмат легасі, який всі боялися чіпати, а Микола, доки всі займались фігнею, прилаштував нарешті конопочку, в результаті чого замовник досі в екстазі. Як їх поміряти, якщо без кожного з них проект стане? Всі ці метрики, як і купа інших скрамів, добре працюють тільки на однотипних проектах з однотипними програмістами.

Артем, scrum.org устал, что все думают, что идея скрама — измерять все сторипоинтами, как метрикой эффективности. И выпустил evidence based management from scrum.org — там предлагают измерять совсем другое. То, что вы назвываете «другие скрамы» — это искаженное представление о скраме по причине наших реальностей и разнообразных контекстов )
А вообще — согласен с вами, и добавлю — когнитивный труд — его качество и количество еще никто не научился объективно измерять. И это — хорошо. Иначе стал бы вопрос о том — кто насколько гениален, а тут уже и до дискриминации недалеко )

scrum.org устал, что все думают, что идея скрама — измерять все сторипоинтами, как метрикой эффективности

Я так понимаю, не «всё», а затраты.

И выпустил evidence based management from scrum.org — там предлагают измерять совсем другое.

И какая связь оценки нужности/ценности разработки с тем, какие на неё затраты?

Если уж говорить про SCRUM в целом и его «мозговой центр» в виде сайта, я бы в первую очередь ожидал хотя бы приблизительной метрики, насколько вообще скрам применим в конкретных случаях (как минимум, зависимо от задачи, от формата/состава команд и т.д.), и чтобы это было написано в виде каких-то roadmapʼов, которые надо было бы проходить для получения ответа на «подходит ли это нам, и если да, то каким именно путём идти?»
Вместо этого таки куча восторженных оͣбстракций, с тем, что основные ресурсы уходят на их адаптацию к реальному миру.

Этот путь прописан в гайде, что лучшие процессы делают сами команды. Скрам для эмпирического подхода, там, где он не применим, скрам не применим. Смастера это знают.
Такая матрица тоже есть. Называется stacey matrix.
Проверочная метрика — если ваши эстимейты сходятся с фактом — значит вы в зоне simple , complicated, если расходятся — complex, если очень расходятся — тогда chaotic
Для двух последних и есть скрам.

Смастера это знают.

Шмастера :)

Проверочная метрика — если ваши эстимейты сходятся с фактом

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

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

Что НЕ делал бы я:
— не мерял количество строк кода
— не мерял количество его времени в офисе
— не делал вывод на основании 1-2 спринтов, а искал бы системность хотя бы на протяжении полугода.

Что бы ДЕЛАЛ я:
— мерял укладывается ли разработчик в количество условных story point — нормы в спринт
— количество багов, которые произвел разработчик на дистанции, относительно других
— количество не успешно пройденных код-ревью
— со сколькими областями проекта работал разработчик
— тратит ли разработчик время на помощь другим
— доступен ли разработчик в рабочие часы
— может ли разработчик красиво подавать информацию клиенту
— находить ли разработчик новые проблемы, с которыми мы столкнемся, помогает ли увидеть будущие риски

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

Для чего метрики:
— определить A-players вашего проекта, работать на их удержание, и развитие в рамках проекта
— определить наименее ценных людей, которых можно в случае сокращения команды сократить первыми
— cмотреть на метрики в случае пересмотра компенсация и повышения грейдов
— определить «норму» выработки для новичков

Анекдот: Спорят грузин и армянин. — Армяне лучше, чем грузины! — Чем? Ну чем они лучше?! — Чем грузины.

Я к тому, что Вы предлагаете свой набор метрик и говорите, что использовали бы их. Чем они лучше тех, которые описаны в статье? ;)

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

Формализация метрик — это утопия. Результат формализируется пост-фактум, всегда. Так и метрики. Все на субъективном предвзятом отношении но в рамках.

А причем тут мнение других ? Они объективные ровно на столько, на сколько преследуют задачи свои. Для других задач — другие метрики.

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

Увольняют не из-за метрик. А из-за невыгодности совместного сотрудничества. Метрики лишь один из подходов формализации и нормализации взгляда на ситуацию.

Увольняют не из-за метрик. А из-за невыгодности совместного сотрудничества

Это если менеджеры осознают реально плюсы и минусы конкретного сотрудничества. А если они измеряют метрики?

Нанимал. Что я должен был понять?

Однажды фиксил багу в старом легаси: несколько сервисов, облако, сервисы написаны на 2-х языках. Кейс попался очень сложный, потратил 1,5 недели, фикс в 2 строчки, как это оценивать?)

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

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

У любого инструмента есть свое назначение и ограничения. Вы же не будете жаловаться на молоток, потому что не можете распилить им бревно? ;-)

то, что вы описыватете не совсем программирование

Если не заниматься терминологической эквилибристикой, то описаный кейс — это вполне типовая история для человека, работающего по вакансии «программист».

У любого инструмента есть свое назначение и ограничения.

Эта музыка будет вечной.

— Мне тут производительность померять...
— Возьмите молоток!
— Да как-то не получается им мерять.
— Ну у любого инструмента есть свое назначение и ограничения!

на галерах работающих с легаси кодом, это и есть обычная работа. задача на 8 стори пойнтс! 3 дня потратить чтоб понять как эта хрень работает , потом добавить и удалить строчку в одном месте, максимум 5 минут.

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

Поэтому если вы не писали код

так блин само написание кода всегда занимает меньше всего времени чем «думание» независимо от сложности задачи и объема. Если вы знаете сразу как написать отличный код — то у вас только типовые (Читай шаблонные) задачи. А значит Вас можно автоматизировать, как и все подобное повторяющееся. И это не утопия и не киберпанк. См. WIX? Corezoid и прочие. Мы уже живем в этом мире. Поэтому если для вас основной труд набирание кода.. то и метрики будут так себе :)

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

В соответствии с ними можно расставить уровни оплаты или квалификации, где а — июнь, б — лидер тимы. Все остальное ИМХО от лукавого и плохо пахнет. Особенно всякие «остросоциальные» штуки типа какой у тебя уровень доступности, характер, участие в митингах и т.п. Все это хорошо но без одного выше представленных 4-х стремится по ценности к нулю. Обратное же утверждение неверно. Иначе не было бы remote, freelance и прочей почасовки.

Если с программистами какие-то KPI еще имеют смысл, то как измерять бизнес-аналитиков или лидов?

Я работал в одной банковской структуре, где коллега, числившийся программистом, на деле занимался лидскими делами (согласования с другими группами, работа с бизнес-требованиями, раздача тасков и пр.) В итоге, банковская система по измерению KPI, показывала его как злостного тунеядца (нет коммитов). И стоило больших бюрократический усилий вывести его из категорий программистов, что бы у менеджмента тремя этажами выше не появлялся по его поводу red flag и, соответственно, вопросы.

На счет аналитиков не знаю :) У них своя активность, свой продукт.

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

Вообще все эти аналитические инструменты нельзя давать в руки тому, кто не хочет думать. Есть опасность, что реального человека подменяют набором цифр со всей вытекающей фигней. О таком пишет О’Нил в «Убийственные большие данные» www.yakaboo.ua/...​nnye-bol-shie-dannye.html.
Но с другой стороны это не причина отказываться от AI и от аналитических инструментов в целом.

Тут в комментах уже поднимался вопрос, а зачем эти метрики нужны вообще? Для кого они?

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

Надо на обязанности человека в каждом случае смотреть. По описанию обязанностей вашего тимлида его KPI, скорее всего, перформанс его команды в сумме (и поименно при ревью) и 360 раз в 1-3 месяцев.

Бессмысленны метрики ради метрик. Имеет значение business value, которое приносят те или иные фичи добавляемые в приложение. Иногда это может быть и 1 строчка кода, и 100. и с количеством написанного кода слабо кореллирует

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

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

Отсылки к опыту. Вы делали именно так и у вас не получилось? Так поделитесь своим опытом. А так это выглядит типа — «молоток плохой инструмент, потому что я ударил себя по пальцам».

Я к тому, что если быть конструктивным, то можно что-то новое узнать и чему-то научиться, если конечно есть такое желание :)

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

Я не понимаю как это можно использовать.
Сравнение двух инженеров? Они должны делать одинаковые задачи. А это как правило не так. Потом, результат работы это патч, который что-то убирает, что-то добавляет, что-то меняет. Что тут считаем, метрики до и после?

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

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

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

Ключевая ошибка, из-за которой лишаются смысла все дальнейшие логические построения — не «в профессиях, имеющих дело с материальными объектами», а «в профессиях, в которых в результате действий получается типовый результат». Работа программиста — это использование большого количества (чем больше, тем лучше) приобретенных разнообразнейшим образом (вузы, курсы, опыт, курилка) знаний и навыков как делать надо, и как делать не надо, для того, чтобы максимизировать business value морфируя заданным (или не очень) образом программный продукт(ы). Это плохо формализуется, и плохо оценивается и меряется с точки зрения процесса.

Вы скажете: «но постойте, как же бизнесу принимать решения без цифр, какой программист эффективный, а какой — нет?»
Ответ простой — никак, если бы все было просто и измеримо, айти контор было бы как мафов — легион на каждой станции метро. Весь хардкор ведения технологичного бизнеса в том, что нужно из***нуться и понимать свою эффективность без понимания индивидуальных метрик своего R&D персонала. Проданные часы, ревенью vs стоимость разработки, зависимость процента 5хх от фазы луны — каждый выдумывает свои индивидуальные, контекстные и плохо переносимые метрики.

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

Теоретические книжки это хорошо, но за мой 15 летний опыт все попытки «молодых и энергичных» сравнить зеленое с теплым превращалось в адский треш. Почему? Потому что нельзя измерить сферического коня в вакууме к тому же не имея единой системы координат. Чтобы получить такой бейслайн надо иметь исторические метрики по проектам разных типов, технологий, состава команд... А получить такой датасет априори невозможно.

Реально цікаво, чи вимірюється та складність такими речами, як кількість рядків, параметрів чи змінних у функціях. Одразу порівнюю свій код
int MyFunc(int a, int b) { int c = Func1(a) int d = Func2(b) return Func3(c, d) }

з кодом колег

void Func1() { this.c = 5 * Application.ACointainer.Instance.A } void Func2() { this.d = 10 * Application.BCointainer.Instance.B } void Func3() { this.result = this.c + this.d } .... void MyFunc() { Func1() Func2() Func3() }

або ще краще

void MyFunc() { this.result = 5 * Application.ACointainer.Instance.A + 10 * Application.BCointainer.Instance.B }

то може я — найслабкіша ланка?

Найголовніше, що треба розуміти — метрик складності, якими можна користуватися дуже багато. Тому Ваше запитання виглядає приблизно так: «а поміряйте вашою лінійкою яскравість моєї лампочки».
Залежності між модулями та кількість складових у виразах можна врахувати іншими метриками.

Питання в тому, що Ви не вказали, які точно критерії складності (та підтримуваності) коду застосовуєте. Виглядає, що Ви або забули, або не збирались їх показувати

Ви неуважно прочитали статтю. Критеріем оцінки є складність. Складність можна виміряти за допомогою метрик. Які саме метрики використовувались в статті написано. Як вони рахуються ви можете легко знайти в інтернеті. Все таки передбачалося, що деякий початковий рівень знань (що таке метрики ПЗ ) людима повинна мати.

Прошу вибачення, написав через день після прочитання. Залишилось тільки запитання щодо maintainability. Це воно?
docs.microsoft.com/...​ics-maintainability-index

Так, це воно. Тільки на графіках воно перевернуте, тому що «a high value means better maintainability» , а на графіку навпаки — чим більше, тим гірше, щоб не відрізнялось від інших метрик.

Щодо особистого досвіду, то теоретичні основи щодо метрик отримував в університеті років 10 тому, на практиці користуватись не доводилось.

Треба копати в області теорії хаосу — системи, в яких нема порядку, є складними

Рекомендую познакомиться с книгой «Начала науки о программах» Холстеда М.Х. (1981). Несмотря на то, что книге уже 39 лет от роду, вы найдете в ней достаточно простую и красивую метрическую теорию оценивания программ, основанную всего на 2 метриках (количество операторов и операндов). В идеале оценка качества ПО должна быть независима от личности код написавшей.

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

В таком случае лучше рассматривать 3 типа метрик: 1 — объективные (код), 2 — субъективные (люди), 3 — агрегация (код + люди)

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

Или метрики, или ничего не было

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

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

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

Почему я ушёл из Google
habr.com/ru/post/350374

зато «работать у нас большая честь» :-)

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

Повторю свою мысль об измерении перформанса: Любая, сколь угодно навороченная система оценки, имеет ОЧЕНЬ большую погрешность. Настолько большую, что, фактически, единственным ее применением будет деление оцениваемых на 3 группы: «Топ-перформеры», «Мидл-перформеры» и «Лоу-перформеры». На большее они не способны. Непонимание этого, мне кажется, причина провала таких систем и ненависти к ним.

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

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

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

Во-первых, давайте отделять качество IT продукта от качества контента.
Во-вторых, фанатизм «упоротых фанатов» на чем-то тоже держится. Какими бы крутыми ни были маркетологи Мака, невозможно достичь такого успеха при помощи некачестванного продукта.

ну я имел в виду не качество в смысле отсутствия багов, а юзабилити

Юзабилити от перформанса девелопера никак не зависит (ну кроме лагов). А качество, это как раз, в-основном, отсутствие багов. Потому что юзабилити слишком субъективная вещь.

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

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

Ніхто не говорить за всю «модель ведення бізнесу». Але вони багато в чому неефективні, що не має фатальних наслідків виключно через їх розмір й неможливість конкуренції з боку малих гравців. Вони можуть безкарно помилятися там, де для дрібноти подібні помилки будуть фатальними.

Можете привести примеры в чем именно они не эффективны? С ваших слов, они «много где не эффективны», значит привести хотя бы пару очевидных примеров не должно составить труда.

P.S. Лично я уверен, что эти компании максимально эффективны во всех сферах деятельности. Они не могут почивать на лаврах т.к. как хоть и находятся на верхушке пищевой цепочки, но конкурируют друг с другом. Даже Билл Гейтс постоянно повторяет, что от краха их отделяет 18 месяцев (это о компании с $1трл капителизации).

Колись розробники тоді ще iPhoneOS відмовились від garbage колектора хоч мали його на десктопах, бо вирішили, що він буде гальмувати на мобільних девайсах. Розробники ж Android натомість вставили свою джаву, а на закиди типу чого iPhone має нормальну анімацію, а Android залипає на повному серйозі звинувачували Apple в «читерстві», мовляв, вони тред, що відмальовує UI, з підвищеним пріоритетом пустили — наче юзерам є діло до тих тредів-пріоритетів, їм нормальна анімація потрібна.

Взагалі, з Android там нормально так косяків було на початку, може й зараз є — просто я іншим займаюсь. Наприклад, від початку вони заявляли, що ніякого C/C++ там не буде. Потім, коли ніхто чомусь не кинувся переписувати свій плюсовий софт на недоджаву їхню, додали таки підтримку нативної розробки. Але через економію пам’яті(!) не додали нормальну підтримку плюсів, мовляв, DSO-шки з ексепшенами дофіга важать. В результаті розробники кожної порядної плюсової аплікації змушені були ребілдити тулчейн і тягати з собою кожен свою зібрану libstdc++ — ото зекономили.

Це приклади невдалих технічних рішень. Втім, вони є наслідком рішень управлінських, інженери гугл доволі пихаті, що було видно зі спілкування в гуглгрупах, й не завжди ця пиха співрозмірна з кваліфікацією. Але Google — це Google, вони заробляють на рекламі такі гроші, що їм треба дуже сильно прокосячити, щоб це на чомусь відбилося.

Те саме й з Microsoft. Можна згадати як вони провтикали ринок мобільних девайсів й все ніяк не можуть туди вилізти — але це їх не вбило. Піднялися і почали знову. Бо мають гроші, мають час та натхнення. Для порівняння PalmOS... — де він зараз?

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

(включая пипл менеджмент)

включая пипл менеджмент )) фишка именно в том что в _их_ положении такая «модель ведения бизнеса» достаточно эффективна чтобы позволять им вести «бизнес» в их положении не более того но и не менее

ЗЫ: скажем реклама как источник видимо дохода кажется я только что это уже писал но «реклама» на той же ж мордокниге просто откровенное говно просто реальный дешёвый треш когда какой-нибудь «местный предсказатель» или «местная община национальных меньшин» может шугануть какой-нибудь «рекламный блок» тупо с «охватом аудитории» тупо всех от 18 и старше с другой стороны я что-то не припомню какой-либо массового охвата рекламы например кока-колы или там пива уж не знаю можно ли пиво но колу то точно можно получается «приличные люди» только имеют «представительство smm» но «рекламой» почему-то не пользуются

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

а «бизнес» развивается простым путём поглощений тот же ж мордокнига купил тот же ж инстаграмм а тот же ж гугл купил тот же ж viewdle кстати сейчас где они?

вот тебе и «модель ведения бизнеса» ))

Извини, клингонский не изучал.

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

Вы не пишете — зачем , а это важно. Ибо тот большой труд, который Вы сделали, на самом деле ИМХО нужен только рукамиводству компании, в основном для того чтобы иметь «обЪективный» показатель «полезности» программера, со всеми вытекающими отмазами для «нетбаблабля» :). Есть известный анегдод, как Генри Форд пригласил м-м-м бизнес-консультантов :) оценить работу служащих его офиса. Через неделю ему доложили, что все пашут как папы-Карло и вполне оправдывают свои з-п, но есть один бездельник в кабинете № 20, который целыми днями курит сигары, положив ноги на стол. Форд сказал: «да, я в курсе. Этот чувак в прошлом году сделал несколько предложений по производственному процессу, которые помогли нам сэкономить сотни тысяч. И тогда его ноги занимали то же самое положение». Но тут-то хорошо, «полезность» можно было прямо в бабле и померить :)

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

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

Про карму — это метафора надеюсь :) Но первая мысль вопщем-то подтверждает, что ни универсального, ни хотя бы частично удовлетворительного метода люди так и не придумали.

Но что, если мы захотим подойти к вопросу объективно?

Тоже интересно: откуда возьмется обЪективность, если показатели закладывает конкретный человек? Видимость обЪективности (что есть все-таки лучше, чем невидимость) — да, согласен.

Т.е., я не имею ничего против попыток «объективизировать» труд программера, более того — сам такие делаю. По причине — см. вышее :) Но я их рассматриваю как результат того, что рукамиводитель не имеет достаточного опыта/времени , чтобы оценить своих девов, и-или не доверяет/не делегирует это дело своим заместителям. В идеале такие метрики могли бы разве дополнять и уточнять мнение квалифицированного чифа. Если он неквалифицированный — это конечно совсем другая проблема :)

Например, программист Николай, решая задачу, будет, не вставая со стула, стучать по клавиатуре три дня и создаст множество кода. Программист Василий, обдумывая решение, будет гулять по кухне, общаться с коллегами и бездельничать другими самыми разными способами. Однако за те же три дня выдаст решение, которое по объёму кода в несколько раз меньше, понятнее его коллегам и к тому же работает быстрее. И в том и другом случае задача решена, результат получен. Можно ли сравнить Василия и Николая? Например, чтобы выбрать, кого из них сделать руководителем группы.

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

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

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

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

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

Ну то есть вы сравнили продуктивного говнокодера с нормальным инженером, который чай пьёт и думает, а не стучит по клавиатуре. Хм... кто же из них лучше?... Дайте-ка подумать...

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

Зайду издалека. Проводили опрос водителей, чтобы те оценили свой уровень вождения. Выше среднего или ниже среднего. По результатам исследования вышло что 70% водителей имеют уровень вождения выше среднего ;)
Думаю с программистами та же история. Я очень часто слышал рассказы о том, что плохой код, потому, что не было времени. Но ни разу не слышал, чтобы кто-то назвал себя говнокодером.

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

Поделитесь, как Вы определяете нормальность инженера? ;)

как Вы определяете нормальность инженера

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

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

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

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

Так что в этом и смысл — независимо от чего-то мнения посмотреть на коллектив, на всех сразу. Я говорю о инструменте. А как использовать этот инструмент — это Ваше дело. Люди потому инструменты и придумывают, что своих способностей не хватает...

Пожалуйста, прекратите оценивать эффективность отдельных программистов. Оценивайте эффективность команд.

А вы не задумывались почему лидеры индустрии (тот же FAANG), все, как один, оценивают индивидуальную эффективность, и не пользуются Скрамом; при это коллективная безответственность, отсутствие индивидуальных метрик и прочий скрам — это эджайл-удел куда менее успешных компаний?

Один приклад із реального життя. Досвід підключення оплат від Apple medium.com/...​for-ios-apps-8d12b700a98f
Я думаю що з метриками в них все ок, а от результат засмучує... Пропоную кожному самостійно задуматись, чому. Та й історії, коли люди звільнялись з Гуглу через те, що оцінювали не якість коду, відсутність багів, а вміння користуватись іншими людьми, теж не рідкість.

Один приклад із реального життя. Досвід підключення оплат від Apple medium.com/...​for-ios-apps-8d12b700a98f
Я думаю що з метриками в них все ок, а от результат засмучує... Пропоную кожному самостійно задуматись, чому.

Я бы не стал говорить о качестве продуктов эппл как о низком. Думаю, оно существенно выше среднего по рынку. Факапы бывают везде.

Та й історії, коли люди звільнялись з Гуглу через те, що оцінювали не якість коду, відсутність багів, а вміння користуватись іншими людьми, теж не рідкість.

Это подтверждает наличие индивидуальных ревью или опровергает? Это как-то говорит о полезности этих ревью?

пора тебе завязывать с наркотиками

Мне не интересно обсуждать такие вещи, как

коллективная безответственность

. А вот пруфы, на то что лидеры индустрии предпочитают оценку индивидуальной эффективности мне было бы интересно почитать. Поделитесь?

«Предпочитать» можно что-то по отношению к чему-то. Я не знаю, что вы имеете в виду, но я ничего не говорил о предпочтениях. Я говорил про использование или неиспользование индивидуального оценивания «индивидуальной эффективности» или перформанса.
Так вот:
F
A
A
N
G
Единственный, кто отличается — Netflix. Но, тем не менее, индивидуальное ревью есть, просто оно делается в форме оценки 360. Во-вторых, это ревью отделено от ревью зарплаты. Как делается ревью компенсационного пакета, я быстро найти не смог. Попробуйте вы.

Цікаво, чи порнхаб якісь фреймворки викладає в опенсорс...

Качество вопрос, конечно, субъективный. Тут важнее успешность на рынке. Лично я считаю качественным следующие продукты: Гугл-серч, Гугл-мапс, Гмейл — отличные качественные продукты. Фейсбук сам по себе высококачественный продукт. МакОС. Амазон, как интернет магазин. Амазон Алекса. Ну это так, на вскидку. Есть еще куча Б2Б продуктов.
В любом продукте (особенно большом) всегда будут небольшие проблемы. Но их процент крайне незначительный.

гугль норм, фейсбук говно редкостное, амазон норм, электронные книги хорошие, пользуюсь. эппл — 50/50

как вы предложите оценивать эффективность команд?

Методика оценки должна помогать достигать бизнес цели. Для примера рассмотрим продуктовую компанию. У команды есть ownership на часть функционала. Тогда метриками в этой методике будут:
— соблюдение SLA по фичам
— количество и скорость устранения дефектов
— скорость прототипирования новой фичи
— качество и скорость внедрение новой фичи
— и т.д.

Мало какой бизнес будет переходить на уровень «количество строчек кода от одного разработчика».

Только это метрики для C-левела, которые они просматривают раз в неделю/спринт/глобальный факап. Что не может отменять необходимости поиска способа трекать поименный перформанс.

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

так он сказал, что количество багов тоже учитывается

Лычки тоже командам. Синиор команда, при приходе новичков статус автоматически понижается

А зарплатню теж на команду видавати?

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

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

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

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

Я считаю ошибкой, ставить фокус на измерении эффективности отдельного программиста, а не команды в целом. Это приводит к негативным последствиям, подробней в этом видео www.ted.com/...​the_pecking_order_at_work

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

Перформенс ревью это не метрики на индивидуумов. Собственно по вашим ссылкам выше нет никаких метрик. Все сводится к 360 feedback с полями start doing, continue, stop doing. Где метрики то? По какой формуле из этого рассчитывается зарплата? :-)

Перформенс ревью это не метрики на индивидуумов

Если что, я и не утверждал этого :-) Перформанс ревью — это процесс оценки вклада сотрудника в бизнес компании.
Он может включать в себя ревью метрик или не включать его. Я лишь утверждал, что успешные компании включают ревью метрик в этот процесс.

Все сводится к 360 feedback с полями start doing, continue, stop doing.

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

Где метрики то?

Оценка 360 это и есть метрики. Но если почитаете про перформанс ревью в других компаниях кроме Нетфликса (я просто не смог найти информацию о том как именно проходит performance/salary review там) увидите как много там метрик. Те же процентные показатели выполнения OKR.

По какой формуле из этого рассчитывается зарплата? :-)

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

Перформанс ревью — это процесс оценки вклада сотрудника в бизнес компании.

ну вот скажем простой гребец на обычной галере отработал на $2000 галера за него получила $4000 (как говорят в контексте задачи некритично) какая процесс оценка вклада сотрудника в бизнес? много? мало? нормально? какая вообще цель такой «оценки» и что вообще такое «вклад в бизнес»?

Те же процентные показатели выполнения OKR.

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

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

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

вот Вася вот Петя «по оценкам вклада» Вася «вложил» много а Петя нормально в чём разница между Васей и Петей с точки зрения самих Васи и Пети?

Оценка 360 это и есть метрики

Нет, оценка 360 это фидбек от всех „контрагентов” с которыми работает сотрудник. Например фидбек по форме „что начать делать, что продолжать делать, что перестать делать”. С метриками этот фидбек не имеет ничего общего, совсем. Это информация по вашим же ссылкам.

Netflix:
„When we stopped doing formal performance reviews, we instituted informal 360-degree reviews. We kept them fairly simple: People were asked to identify things that colleagues should stop, start, or continue.”

Facebook:
„There is a two week period where employees solicit peer feedback (usually 3-5 peer reviews), and write a self assessment. Managers then read all the peer feedback and the self assessment and determine a ‘Performance Assessment’ or rating of the employee’s performance over the last six months as well as whether or not it is the right time to promote the employee.”

Apple:
Peer Appraisal + 360 feedback
Peer Appraisal „is a method wherein the peers and teammates provide a unique perspective on performance”
360 feedback „is an employee evaluation tool that includes feedback from supervisors, subordinates, colleagues and customers”

Google:
„Google’s annual performance review cycle is comprised of two parts: a ‚preview’, in the end of the first semester, and a complete review, that happens between October and November, and which happens concurrently with the company’s 360-degree feedback collection process.
Managers take two main things into account when attributing their employees’ performance ratings: results attained, or what the employee accomplished, and behaviors, or how the employee attained these results. The employee starts with a self-assessment, which is followed by peer-reviews, whose authors are only visible to managers (reviewees may have access to the anonymized content of peer reviews).”

„Peers are expected to give assessments in three different media: strengths, or things that the person should keep on doing, and weaknesses, or things that the person should consider working on/developing; rating each other on the five criteria discussed above; and finally, commenting on the reviewee’s contribution to specific projects.”

Спасибо большое за аргументацию!
Отвечу на Ваши замечания.
1) Измерение вклада. Я попытался хоть как-то формализовать этот момент. В статье написано, что это не абсолютный показатель. Это лакмусовая бумажка. У вас как менеджера появляется возможность взглянуть на всех сразу. И уже разбираться с подробностями, если кто-то вас заинтересовал. В данном случае не важна ценность фич которые человек делает, вы просто видите, делаел что-то человек или нет.

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

3) Посмотрите внимательно на часть статьи где сравниваются команды (круговые диаграмы). Если не детализировать, то все хорошо. Команды примерно одинаковы. Однако спустившись ниже вы увидите моменты, которые можно улучшить.
К негативным последствием приводит не измерение, а отношение людей к измерению. Если бить палками того у кого хуже метрики, то ни к чему хорошему это не приведет. Но если понять почему метрики хуже и поработать с человеком, научить его чему-то новому, вы получите профит.
Спасибо за видео. То, о чем там говорится хорошо описано в книге «Культурный код» Койла и «Эмоциональный интеллект» Гоулмана.
И последнее. Анализ кода может показать связи и коммуникации в коллективе. Зависимости в проекте коррелируют с коммуникациями между командами.
Думаю в знаете закон Конвея ru.wikipedia.org/wiki/Закон_Конвея

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

В этом случае автоформатинг ни на что не повлияет.

Один вкомитал 100500 сторк кода, второй придумал ввести форматирование, переформатировал все 100500 строк и вкомитал. По метрике оба работали одинаково...

Если бить палками того у кого хуже метрики, то ни к чему хорошему это не приведет

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

Узнали Dev-2/3 что Dev-1 похвалили за cyclomatic complexity? Тут же стали лепить 5 методов в один с кучей if-ов и всяких вложенных блоков — и в метрике сразу догнали первого бедолагу, который партачил ранее своим не-clean кодом. Profit?..

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

С дуру можно и *** сломать. Почему в контексте индивидуальных метрик постоянно рассматривается 2 крайних варианта — формула, в которую просто загоняются данные и выдается результат и отсутствие каких-либо метрик? Это как спор кем быть лучше — жирдяем с весом 200+ или анорексичным дистрофиком 35 кг.

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

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

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

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

Метрик много

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

если ты пытаешься удовлетворить одной, страдает другая

Зачем тогда эти метрики? :D
На самом деле разговор беспредметный. Надо смотреть конкретные случаи с конкретными метриками — так мы говорим о сферических в вакууме.

метрики возможность формально это оценить

Не возможность. Никакая метрика не измерит качество кода.

Думаю вы не разобрались, что именно метрики показывают. И второе для чего их применять. Логическая цепочка:
— метрики дают возможность оценить сложность кода. В данном случае это совокупность показателей, каждый показывает что-то свое; Кроме того они связаны: уменьшил цикломатическую сложность — увеличил количество методов.
— чем сложнее код пишет программист, тем хуже для проекта, тем тяжелее работать с єтим кодом.
— получив набор метрик по коду написанному программистом, можно научить его писать код лучше.

И ваше высказывание "

Никакая метрика не измерит качество кода.

" декларативно. Метрики для того и нужны, чтобы измерять.

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

Шок! Эффективный менеджер спустя 25 лет работы в индустрии узнал, что эффективность программиста измеряется не только в строчках кода, но и в их полезности!
Сколько еще лет понадобится, чтобы узнать, что коммит в котором код удаляется может быть в разы полезнее, чем тот в котором он добавляется? Или что техлид, который может писать 10% кода от рядового синьйора, тоже полезен?

Вы здесь не учитываете два очень существенных момента:
1. Ценность программиста — это не только ценность написанного кода. Это еще и количество решенных ДЛЯ БИЗНЕСА задач. То есть человек может писать код с меньшим PR, но важнее для бизнеса. И это вряд ли можно будет увидеть по каким-то метрикам кода, но учитывать это важно.

2. Качество кода определяется не только навыками программиста — но еще и поставленной задачей, а иногда и сроками. То есть, если программист обычно работает над более сложными задачами, то средняя сложность его кода тоже может быть выше.
Не обязательно так, может быть и наоборот, но я бы это учел — иначе вполне себе можно сделать выводы, ПРОТИВОПОЛОЖНЫЕ реальному положению дел.

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

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

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

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

К сожалению опрос может быть еще менее показательным. Если опрос анонимный, то это возможность свести счеты. Тот опрос который я видел скорее показал кто наименее конфликтный, чем то кто более профессиональный.

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

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

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

Будет как в анекдоте:

Однажды Вано залез на дерево, а слезть не может. Мимо идет
Гиви, смотрит — Вано на дереве сидит.
(Г): — Ты зачем на дереве сидишь?
(В): — Да, панимаишь, слезть не могу.
(Г): — Сейчас я тебе помогу, слушай, только никуда не уходи.
Через некоторое время Гиви прибегает с веревкой, кидает один
конец Вано.
(Г): — Только веревку ни к чему не привязывай и держись за
нее крепче.
(В): — Харашо, Гиви.
Гиви сильно дергает за веревку — Вано падает с дерева.
(В)(обиженно): — За что, Гиви?
(Г)(недоумевающе): — Слушай, меня недавно так же из колодца
вытаскивали.

В «гипотезе» для полной «объективности» нехватает третьего варианта — человек создал бога.

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

Например:

И если мы можем использовать Page Rank для определения важности документа, то почему бы не применить его к коду?
Итак, вкладом программиста в проект я буду называть объем написанного кода, умноженный на его PR.

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

да, как и у любого инструмента есть границы применимости и оговорки по результатам

По поводу рекомендательного характера на 100% согласен. Я в комментарии выше об этом писал.

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

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

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

Підписатись на коментарі