Comments 36
Лол. Смешно мерить эффективность по количеству строк кода, количеству PRов и т. п.
Для типовых задач, для одной должности и на длинном интервале — вполне себе метрика. Вот как ее использовать? Это уже искусство руководителя. Но, как пишет автор, проблемы можно заметить. Есть люди, которые создают шум, а выхлопа от них мало. А есть те, кто не соблюдает сроки, но по факту затаскивают весь проект...
Но для меня это хоть что-то, а не просто: «Этого разработчика не видно, зачем ему повышение?» Или: «Он как-то допустил баг, поэтому он дурак». Не люблю субъективизм. А из цифр — только это.
Эти метрики дефективных менеджеров для отражения на дашбордах. Потом по итогу появляется такое понятие как покраска заборов. Количество строк кода и PR никак не говорит о состоятельности или вкладе разработчика в проект. Изменения могут быть значительные, но не важные.
Проблема такого подхода в том что он НИКАК не коррелирует со сложностью и качеством работы. Такие метрики выводят в топ безответственных кодеров, они поощряют создание "артефактов" и имитацию деятельности: больше кривого кода -> больше багов -> больше тикетов -> больше фиксов -> больше ревью -> больше мержей -> больше документации для описания полученного монстра с бесконечными правками по каждому изменению.
Я видел как команда собранная из таких "топ-перформеров" быстро превращает проект в ужас, планка код-ревью там на уровне "компилится и ладно", а когда наступает критический момент тим-лид получив повышение сваливает в закат. В итоге проект невозможно дальше развивать - простейшие изменения занимают недели, все тормозит и разваливается от малейших правок, по коду ходишь как по минному полю с шансом запустить цепную реакцию.
Ну и "low-перформер" который коммуницировал с другими командами вместо того чтобы писать неверный код по неправильному контракту, это конечно вишенка на торте.
P.S. для любителей померить погоду на Марсе есть готовые инструменты https://marketplace.atlassian.com/apps/1210934/awesome-graphs-for-bitbucket
А как надо мерить? По количеству "Ты меня уважаешь?" на совместной пьянке? Или по тому как программисты льстят лиду?
Автор хоть какие-то объективные метрики внедряет, автор молодец
Я не фанат оценок сотрудников по количеству PR и строчек кода, но думаю такой подход можно использовать в дополнение к стандартному performance review (чтобы разработчики не фокусировались на количественных показателях).
Есть вопрос: Когда считаете строки кода, учитываете только добавление строк или удаление тоже? Одинаково считаются тесты и основной код?
Учитываю и редактирование и удаление тоже. Тесты и основной код считаются одинаково, чтобы не усложнять подсчеты.
Тогда большое пространство для увеличения размера кода, например вместо ParameterizedTest создать 20 тестов, разбивать тесты и т.д.
А у вас эта метрика единственная или вы все такие собираете фидбэки и самооценку? Если описанная в статье метрика единственная, то есть шанс довести все до абсурда. Чтобы стать "Топ перформ" разработчикам, достаточно открыть книжку дяди Боба про чистый код и можно добиться отличных результатов, доводя все до абсурда.
(Буквально на днях читал здесь про интересные репозитории https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition). Да и AI в этом очень сильно поможет, если надо раздувать кодовую базу.
А разработчики под вашим руководством в курсе методы? Или хотя бы в курсе ее наличия?
Я бы к вам на работу не пошёл. Начнём с того, что с момента, как вы формализуете метрики, программисты начинают работать на метрики, а не на результат.
Будут драки за код-ревью, потому что ревьюить выгодно, а писать код - нет. И закрывать тикеты не выгодно, потому что их могут переоткрыть, а это сразу минус пять тысяч написанных строк кода. И не важно потом, правильно ли был тикет заведён, правильно ли был переоткрыт.
У меня был период, когда я за пару месяцев снёс около 6к строк кода из большого проекта. Писал новый функционал и тестеры переоткрывали мои тикеты. Потому что моя работа - исправлять, а их работа - проверять.
По вашей методике я бы просто остался без зарплаты. Хотя объективно я в краткий срок запилил очень жирную фичу.
Поддержу автора. Без хоть какой-то метрики сложно оценивать результаты разработчиков, когда команда из 5 человек в одном проекте, легко, когда переваливает за 10 с разными проектами, тут необходимо переходить на уровень выше и выстраивать систему оценки.
Многие критикуют и сразу с ходу льют говно не разобравшись. Я считаю что команды должны знать что их работа анализируется, также они должны знать зачем и для чего это нужно. К сожалению, многие Лиды пропускают пункт с объяснением, а тупо вводят скриптовые сценарии.
Также некоторые забывают что выше есть дяди в пиджачках и они понимают только язык цифр, им не интересны отчеты в стиле «Петя крутой поднимите зарплату».
Лично мой кейс, я помимо софт/селф/сёр скиллов разработчика смотрю на его профит: сколько он сделал реквестов которые дошли до прода, сколько привнес вклада в наш вики, сколько ревьювил и какое кол-во комментарий оставлял (их их качество).
Конечно, это тезисно и у каждого такая система уникальна, именно под "их" команду/компанию. Поэтому глупо говорить «зачем они считают строки кода?», да может им это важно и необходимо?
Людям, которые в танке и для которых существует только черное и белое у меня есть простой совет - делайте свое дело, запускайте свои продукты, собирайте свои команды. Тогда вы сделаете все как сами захотите, с Блекджеком и шлюпками.
Я считаю что команды должны знать что их работа анализируется
Вот именно, что работа должна анализироваться. Внедрение KPI - это не анализ, это попытка отмахнуться навсегда от анализа, т.е. совершенно противоположное.
Без хоть какой-то метрики сложно оценивать результаты разработчиков
Если вы не понимаете, что каждый человек делает - да. Только в этом случае метрики вас не спасут. Как я уже сказал, метрики покажут тех, кто лучше приспособился к метрикам.
А как вы понимаете что каждый человек делает? Вы же тоже оцениваете по каким-то критериям?
Я же говорю это вопрос масштаба, работа в одном кабинете с 5 разработчиками и на удаленке с 50 разные вещи.
Как вы определяете какой человек должен повышаться, а второй хитрый бездельник?
Программисты - это не рота солдат. Они должны работать небольшими командами и в каждой команде должны быть свои тимлиды, ПМ, аналитики и другие ответственные лица.
Если вы не понимаете, что делает человек - вы не в праве оценивать его труд. Точка.
Перекладывание ответственности на метрики сделает хуже в первую очередь именно вам. Или сами углубляйтесь в детали работы каждого, либо доверьтесь ответственным лицам за каждое направление.
А как вы понимаете что каждый человек делает?
Вообще не понимаю, откуда такие вопросы могут взяться. Вы не пробовали поговорить с сотрудником, с его командой? Вникнуть в пул его задач?
Это замечательно, что у вас нет аналитики и вы общаетесь с каждым разрабом, анализируете его труд за полгода/год, в общем, подходите к каждому максимально индивидуально.
Предлагаю вам написать свою статью и показать, как правильно нужно оценивать разработчиков. Может быть после прочтения я сменю мнение в этом вопросе
Это плохо завуалированное послание "сперва сам добейся". Это очень некрасивый ход. Я бы сказал, что недостойный.
Писать статью, чтобы убедить одного анонима в интернете? Я слишком рационален для того, чтобы тратить столько усилий впустую.
Тем более, что свою точку зрения я высказал и Вы её услышали.
вы общаетесь с каждым разрабом, анализируете его труд за полгода/год, в общем, подходите к каждому максимально индивидуально
Так и должно быть. Это называется работа. У программистов индивидуальные задачи, индивидуальные способности, индивидуальные области знаний. Оценки тоже должны быть индивидуальными.
Я вам порекомендовал написать статью, а не пытался принизить ваше мнение.
Я слишком рационален для того, чтобы тратить столько усилий впустую.
А зачем вы вообще в дискуссию вступаете? Я не отвечал на ваш комментарий выше, вы услышали мое мнение, я ваше. Если для вас это больная тема, раз вы так яростно строчите слова, напишите статью, выскажите свою точку зрения, может многим она будет полезна = для вас рациональна. Видимо, комментарии не попадают под НЕ рациональное.
Так и должно быть.
Опять же, по вашим словам это - закон и противоположное не имеет право на существование.
А зачем вы вообще в дискуссию вступаете?
А Вы не понимаете, что мы на паблик ресурсе, да? Моё мнение видно не только вам - вот вам ответ.
раз вы так яростно строчите слова, напишите статью, выскажите свою точку зрения
Ещё раз. Я не подросток, которого можно взять на "слабо" и мотивировать такими насквозь манипулятивными методами.
Опять же, по вашим словам это - закон и противоположное не имеет право на существование.
Знаете, чем отличается моё мнение от Вашего? Моё имеет хоть какие-то аргументы.
Кстати, минус в карму поставил я. За неконструктивное общение. Мне надоело объяснять элементарные вещи.
Пукан то загорается? Не переусердствуйте, тушить долго придется.
Знаете, чем отличается моё мнение от Вашего? Моё имеет хоть какие-то аргументы.
Знаю чем, вы любите проявлять аффектацию. Учитывая что первым делом в дискуссии побежали понижать рейтинг, вас мое мнение видимо очень сильно подожгло пятую точку.
Знаете чем отличается мое мнение от вашего? Я принимаю чужую точку зрения и не пытаюсь переубедить, о чем я несколько раз сказал в надежде что вы замолчите.
В любом случае, я бы к вам на работу не пошел 😂
Кстати, минус в карму поставил я. За неконструктивное общение. Мне надоело объяснять элементарные вещи.
😂😂😂
"стартыйдобрый" аджайл:
Сложность стори выставляется командой - сколько решают поинтов, столько и ставят, можно обсудить.
Если тикет/стори выполняется одним человеком - посчитайте поинты - и все вопрос решен. Если несколькими, тут сложнее, или пилить на substory, или как-то делить поинты.
Скрам мастер в том числе смотрит, чтобы команда не накручивала поинтов, по сравнению с дугой командой.
Ерунда какая-то. Если такой KPI всплывёт, то никто не будет закрывать потенциально переоткрывемые таски. В лучше случае, их будут бесконечно дробить, в худшем держать максимально долго открытыми. Команда вообще может быстро сорганизоваться, чтобы делать noop code reviews. Или вообще устроят настоящую игру в кальмара.
Если держать эти метрики в секрете, то люди, которые делают самую сложную работу, скорее всего останутся в аутсайдерах. Реверсить что-то действительно на порядок сложнее, чем kLOCи с stackoverflow копипастить, архитектуру править, так если не будет переоткрытия тикетов, то это не править, а просто вокруг походить, а уж если по поводу api/архитектуры с другими командами договариваешься, когда за неделю весь прогресс - полстраничка в wiki, это бывает вообще будущее проекта определяет.
Если менеджер сам лично в совещаниях команды не участвует, то пусть тогда и в перформанс оценку не лезет. В одной компании, где я работал, очень просто поступали. Раз в квартал просили написать, кто и почему из команды хуже всех перформит и кто лучше всех. Результаты голосования не вели к непосредственным действиям, просто менеджер чуть больше обращал внимания на первые и последние места. Иногда 15 минутного правильно выстроенного разговора с аутсайдером достаточно, чтобы он признался, что в страшном сне вообще эту команду/компанию видел.
Но жизнь вообще штука сложная. Один мой хороший знакомый, зная, что в компании ввели подобную KPI, весьма отчаянно хотел пойти на сокращение. Три зарплаты за 0 месяцев - неплохой бонус, интереснее, чем плюс одна за 12 месяцев. Сообразивши, что KPI может выглядеть примерно, как вы описали, делал так. Взял две самые стремные таски, одна из них связана была с нигде не описанным функционалом ОС, вторая с очень нетривиально воспроизводимыми проблемами с сетевым взаимодействием. Эти таски все равно бы никто из других участников команды не взял. Реверсинг за 3 месяца дал 120 строчек кода, короткую вики страницу и закрытый таск с низким приоритетом. Исправление сетевой архитектуры дали образ с эмуляцией сетевых проблем, фикс на 50 строчек, десять из которых операторы goto, ноль документации. Код ревью это прошло, потому что проходились тесты, а никто из остальных членов команды не хотел даже пытаться предлагать что-то лучше. Итог за 6 месяцев, порядка 300 строчек кода, одна страница в вики, две закрытые таски с low-priority, два мержа, ноль ревью, ноль открых задач. Сколько там по вашему KPI? Сотки не будет, когда у остальных коллег от тысячи. Сокращение?
А вот и нет. Повышение. Как оказалось, за месяц до закрытия этих задач, один из крупнейших пользователей продукта, заявил о том, что не будет продлять лицензию, потому что продукт не проходит его внутреннюю систему проверки качества и безопасности. Но о деталях этой проверки не сообщал. Менеджмент решил пойти в олл ин и сказал, попробуйте все же новую девелопмент сборку, типа мы мол кучу проблем решили. Кастомер не спешил, через месяц скачал сборку, и о чудо, она прошла внутренние тесты, которые как выяснилось потом касались именно этих двух low-priority задач. Итог для компании, продолжение многомиллионного контракта, и не в рублях. Итог для разработчика - сравнительно ерундовая прибавка, вместо более выгодного ему сокращения.
Реверсинг за 3 месяца дал 120 строчек кода, короткую вики страницу и закрытый таск с низким приоритетом.
Наверняка же этот код как-то тестировался, были какие-то скрипты и т.п. Реверс инжиниринг без этого не делается.
Нет, из безусловно полезных артефактов это все. Тесты на этот функционал были давно написаны и окружения, на которых они "мигали" добавлены в систему тестирования. Собственно, так таска и появилась.
Были и другие артефакты, но они никаким местом к репозиторию проекта не относились, горстка скриптов, создающих минимальное проблемное окружение относительно именно этой проблемы, декомпайлы другого продукта, который успешно работал в этом окружении, дампы памяти с расшифровками - все это отправилось на местную версионную файлопомойку. И без вики было бы тут же забыто как страшный сон.
Если такой KPI всплывёт, то никто не будет закрывать потенциально переоткрывемые таски.
Речь не про таски, а про переоткрытые дефекты, нацелено это на повышение качества кода.
Иногда 15 минутного правильно выстроенного разговора с аутсайдером достаточно, чтобы он признался, что в страшном сне вообще эту команду/компанию видел.
Ключевое слово в этой фразе - "иногда":)
Речь не про таски, а про переоткрытые дефекты, нацелено это на повышение качества кода.
Я написал длинную душную простыню с целью показать, как же тонка разница между таской и дефектом, но, пожалуй, лучше спрошу, в чем максимально формализованное различие между этими понятиями для Вас?
Ключевое слово в этой фразе - "иногда":)
Иногда есть подозреваемый, его мотив, орудие убийства, которое он использовал, жертва, убитая этим орудием, и тогда подозреваемого можно считать обвиняемым. Часто у подозреваемых нет такого набора. Как правило правосудие не ставит задачи посадить как можно больше подозреваемых. Вот вам и "иногда" и "часто" и "как правило" в одной конструкции, какое из них ключевое? А у Вас, как воспринимается, основная директива: "преступник должен сидеть в тюрьме".
"если человек приходит на работу, значит он скорее всего что-то делает"
Это утверждение не просто спорное, оно ложное. То что человек приходит на работу значит только то что он сидит на стуле на территории работодателя. Больше ничего.
"вряд ли работа одного и того же разработчика будет состоять только из фикса багов повышенной сложности"
Если ваш коллектив не состоит из одинаковых клонированных сотрудников - перекос по сложности решаемых багов будет обязательно.
"В данном случае можно периодически проводить ревью созданных страниц"
"Ответ – не пропускать такие mr на ревью."
То есть система, предназначенная для упрощения и автоматизации оценки производительности сотрудников требует ручной работы и микроменеджмента.
Выглядит так, что это все применимо только на эталонной галере в вакууме с обезличенными сотрудниками. Откуда там мотивация у сотрудников "не пропускать на ревью" такие мр-ы - не понятно.
У меня сложилось впечатление, что у автора либо очень узкий опыт по типам компаний, либо малый опыт управления командой. Обычно такое и приводит к поиску "волшебной спасительной формулы". Может, вам стоит посмотреть в сторону разбиения команды на подгруппы с ответственными за эти подгруппы, а не пытаться охватить в одного всё с использованием сомнительных формул?
"если человек приходит на работу, значит он скорее всего что-то делает"
Это утверждение не просто спорное, оно ложное. То что человек приходит на работу значит только то что он сидит на стуле на территории работодателя. Больше ничего.
Именно об этом я и написал: "До пандемии коронавируса преимущественно во всех IT компаниях сотрудники работали в офисах, и, если человек приходит на работу, значит он скорее всего что-то делает. В 2020 году ситуация усугубилась, все ушли на удаленку, а инструментов оценки эффективности попросту не оказалось."
Утверждение действительно ложное, поэтому мне и хотелось опираться на какие-то числовые метрики.
Если ваш коллектив не состоит из одинаковых клонированных сотрудников - перекос по сложности решаемых багов будет обязательно.
На дистанции в 1 год такой перекос не будет ярко выражен.
То есть система, предназначенная для упрощения и автоматизации оценки производительности сотрудников требует ручной работы и микроменеджмента.
Не было задачи полностью автоматизировать процесс, суть была в том, чтобы получить объективные метрики оценки. Ручной труд менеджера действительно нужен, я это подчеркнул в тексте, не вижу тут никакой проблемы.
По годовой статистике не совсем согласен. Это зависит от проекта, может у вас и правда так. Но часто видел, что на сложных проектах разные части системы поддерживаются разными разработчиками. И, соответственно, и баги у них отличаются по сложности этих частей. Если система однородная, то, может, и выровняется.
Про ручной труд - у меня сложилось впечатление, что в предложенном подходе его не сильно меньше, чем при обычной оценке по дейликам и списанному времени. А где ручной труд, там и субъективизм. Просто тут он более "гранулярный", что ли.
В конечном то счете смысл всех оценок должен быть в оценке импакта на бизнес, а не на количество кода или строк документации.
Короче - время покажет. Наверняка же вы дорабатывать и корректировать что-то будете в этой схеме. Интересно, к чему придёте.
Поиск объективных метрик, это хорошо, но работа программиста заключается не только в написании кода. Представим, программист А берёт фичу и видит, что она, например, конфликтует с каким-то другим функционалом, ну или просто, по мнению разработчика, дизайн фичи можно улучшить. Он идёт к аналитику, задает вопросы, предлагает свои решения, спорит и т.д. Это всё занимает время. Когда фича готова, разраб получает баллы за написаный код, но его вклад в дизайн никак не оценивается. Пока программист А коммуницировал с аналитиками/клиентами, его коллега - программист Б просто тупо пилил, что написано и вопросов не задавал, и по итогу у него будет больше баллов. Но если выбирать из этих 2х программистов, то я бы однозначно выбрал бы первого.
Информация, которая передается только голосом от одних людей другим, и почему это плохо - это тема отдельной дискуссии. После таких созвонов должны оставаться артефакты - коменты в тасктрекере, странички на wiki, дизайн тоже где-то фиксируется, так что все то, о чем вы написали фиксируется при подсчете.
руковожу отделом разработки эквайринга в системно значимом российском банке
Кажется, в статье описан довольно типичный менеджмент разработки в банке — антигуманный. Разубедите меня, если я неправ.
Как оценить индивидуальный вклад разработчика в проект