Критерии оценки эффективности программиста

[Komissar]

[YevgenyN]

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

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

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

[valchkou]

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

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

согласен, это не qa vs prog, и те и другие на одной стороне - на стороне работодателя.
А вот клиент совсем другое дело. Имеет смысл оценивать продакшн по количеству именно критических багов, которые несут риск потери клиента/репутации/денег.
Да и то не всех, только начиная с уровня 3-4 года опыта. Понятно что жуниор, без хорошего ревью, своим кодом может всех клиентов распугать.
то есть если я к примеру пишу всякую фигню на привет, и вот после очередного апгрейда фигня не отправляется - это не критичный баг, сегодня возьму паузу, а завтра возьмусь за старое с новой силой.
Но совсем другое если кто то отправил сообщение экстремистского характера, а на форуме оно светится как мое.
Набегут боты, затем АНБ, вычислят мой ник, адрес и потом доказывай что не верблюд.

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

[Albert_al]

Нужны критерии оценки сложности - иначе все насмарку. LOC в топку

[valchkou]

Нужны критерии оценки сложности - иначе все насмарку. LOC в топку

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

[Мальчик-Одуванчик]

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

У нас индуски из QA только этим и занимались.

[Мальчик-Одуванчик]

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

При уровне хотелок бизнеса багов будет только больше.

[picolga]

В основном задачи хватает )

[sp123]

Работал как-то в начале 2000-х в одной команде с очень хорошим и опытным местным мужиком. Тот перед этим поработал в "компании по производству контроллеров для мотороллеров" Motorola . Рассказывал, что там была очень забавная практика. Считалось, что если в QA выкатывался абсолютно чистый код без багов, то это говорило о недостаточной интенсивности работы программера. Типа, у товарища было время вылизывать код вместо ударного труда. В результате каждый программер имел в запасе пару-тройку мелких багов, которые вставлял в код и потом успешно и быстро чинил перед релизом. Было хорошо всем - и ему, и QA, и тупорылому менеджменту, придумавшему эту хрень.

Глупость LOC уже обсуждали. За >30 лет в разного рода компаниях я такое чудо наблюдал только один раз. Было это на заре перестройки в разгар кооперативного движения и центров НТТМ, когда программеры вдруг стали работать "по договорам" и рубить несусветные бабки. Чтобы как-то формально обосновать расценки и честно поделить бабло между сочастниками один менеджер попытался толкнуть этот подход. Идея вызвала нездоровый смех и была быстро похерена.

Допускаю, что LOC подход еще где-то и существует. При уборке колхозной картошки или клепании тупого кода по шаблону. Давеча нашей команде перепала довольно нетривиальная куча чужого кода, и мы полгода его утаптывали. То есть берем кусок говна в 4000 строк и делаем из него 200.
Рефакторинг делался вынужденно, ибо вносить сколь-нибудь серьезные изменения в существующий copy-paste код было просто нельзя, так как для этого требовался copy-paste в прогрессии. С точки зрения LOC нашу производительность можно смело назвать отрицательной. Можно возразить, что мусорный код надо вылавливать и подавлять на этапе code review. Но это в нормальной команде, а не там, где LOC и тому подобные глупости.

[Херовимчик]

Вообще не совсем понятно зачем придумывать велосипед. Эффективность меряется business impact, а там уже не важно было это 10,000 строк или подправленная одна. Сделал это джун или принципал тоже на прибыль/убытки не влияет

[xrundel]

Вообще не совсем понятно зачем придумывать велосипед. Эффективность меряется business impact, а там уже не важно было это 10,000 строк или подправленная одна. Сделал это джун или принципал тоже на прибыль/убытки не влияет

Тогда какой дурак будет вещи с небольшим business impact?:)

[xrundel]

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

LOC для того и меряют что бы команда с умным видом полгода не утаптывала 4,000 строк

[Херовимчик]

Вообще не совсем понятно зачем придумывать велосипед. Эффективность меряется business impact, а там уже не важно было это 10,000 строк или подправленная одна. Сделал это джун или принципал тоже на прибыль/убытки не влияет

Тогда какой дурак будет вещи с небольшим business impact?:)

А это уже задача менеджера распределять задачи и сохранять баланс между рутиной и high impact projects. Менеджмент это не только щеки раздувать

[valchkou]

То есть берем кусок говна в 4000 строк и делаем из него 200.

итого получаем 4200 modified LOC

[xrundel]

А это уже задача менеджера распределять задачи и сохранять баланс между рутиной и high impact projects. Менеджмент это не только щеки раздувать

А как оценивать работу джуниора по business impact системе если он этих business impact задач не получил вообще? А сениор например получил 10 задач, половину сделал хорошо а половину плохо.

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

[sp123]

LOC для того и меряют что бы команда с умным видом полгода не утаптывала 4,000 строк

То есть берем кусок говна в 4000 строк и делаем из него 200.
итого получаем 4200 modified LOC

Юмористы, блин. Вам смешно, а я тогда ругался как собака!

[Херовимчик]

А это уже задача менеджера распределять задачи и сохранять баланс между рутиной и high impact projects. Менеджмент это не только щеки раздувать

А как оценивать работу джуниора по business impact системе если он этих business impact задач не получил вообще? А сениор например получил 10 задач, половину сделал хорошо а половину плохо.

Если менеджер не в состоянии распределить задачи - менеджера на мыло.

[sp123]

Вдогонку совсем банальная вещь. Вот ты, менеджер, считаешь эти свои KPI и LOC-и. Весь такой объективный. А девелопер столкнулся с нетривиальной проблемой в prod, потратил время, починил и вызвал бурный восторг верхнего руководства. Все твои LOC-и при этом автоматически идут лесом, так как в дело вмешался новый фактор. Починка с точки зрения кода может быть один комментарий там и одна строчка кода тут, хотя время потрачено. Иногда много времени. То же самое дизайн, рисование карандашиком, утрясание деталей с соседней командой; то, что раньше называлось discovery phase. Будешь изобретать хитрую формулу с десятком параметров и весовых коэффициентов? Нынче у нас на дворе колхоз а-ля оджайл, в идеале "мы одна команда", случайый тикет из беклога в зубы случайному "ресурсу", думать некогда, надо трясти. В тикет можно вписать story points, в том числе на дизайн, документацию и прочее. А потом эти story points в конце года просуммировать (что само по себе лютый бред), добавить LOC-и, почетные грамоты за внеурочные подвиги, все тщательно перемешать и получить для HR одну из трех искомых величин - below target, on target или above target. Да, так можно. Потом девелоперы пронюхают твои исчисляемые критерии и быстренько сориентируются, будут тебе и story points в полный рост, и миллион LOC-ов, и победить это тебе будет крайне непросто. Как побочный эффект толковые люди свалят, и очень быстро.

Насчет вопроса что бы девелопер хотел видеть от руководителя ответ простой. Спланируй работу, раздай задачи на очередной двухнедельный спринт и отвали. Будут вопросы - спрошу.

[Херовимчик]

Мне руководство намедни сделало лучший подарок - право самой выбирать когда и над чем работать, с возможностью послать лесом своего непосредственного начальника если его задачи мне не интересны. Цена? Ответственность над растравление приоритетов полностью на мне, в случае чего валить не на кого

[Big Cheese]

Мне руководство намедни сделало лучший подарок - право самой выбирать когда и над чем работать, с возможностью послать лесом своего непосредственного начальника если его задачи мне не интересны. Цена? Ответственность над растравление приоритетов полностью на мне, в случае чего валить не на кого

Хмм.. Мне одному кажется, что это скорее подпрок непосредственному начальнику?

[Херовимчик]

Мне руководство намедни сделало лучший подарок - право самой выбирать когда и над чем работать, с возможностью послать лесом своего непосредственного начальника если его задачи мне не интересны. Цена? Ответственность над растравление приоритетов полностью на мне, в случае чего валить не на кого

Хмм.. Мне одному кажется, что это скорее подпрок непосредственному начальнику?

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

[katit]

Будучи программистом я как-то не сталкивался никогда с тем что меня "оценивают". Наверное это к лучшему
А так - все в этом топике правы, а самое главное что фиг ты оценишь обьективно. То что писал Комми про своего босса наверное самое оно, мне ближе к душе. Я хочу чтобы мои программисты не выполняли тупо ТЗ а понимали для чего это будет сделано, видели систему более шире. Вся эта фигня баги, шмаги, ревью и т.д. в идеале должны отсутствовать. Вот это и будет метрика. И да, при этом если программист смог оценить свое время правильно и уложиться в срок. И меня не будет волновать в какие дни у него небыло настроения написать какого-то кода. Главное - результат.

[Albert_al]

Вдогонку совсем банальная вещь. Вот ты, менеджер, считаешь эти свои KPI и LOC-и. Весь такой объективный. А девелопер столкнулся с нетривиальной проблемой в prod, потратил время, починил и вызвал бурный восторг верхнего руководства. Все твои LOC-и при этом автоматически идут лесом, так как в дело вмешался новый фактор. Починка с точки зрения кода может быть один комментарий там и одна строчка кода тут, хотя время потрачено. Иногда много времени. То же самое дизайн, рисование карандашиком, утрясание деталей с соседней командой; то, что раньше называлось discovery phase. Будешь изобретать хитрую формулу с десятком параметров и весовых коэффициентов? Нынче у нас на дворе колхоз а-ля оджайл, в идеале "мы одна команда", случайый тикет из беклога в зубы случайному "ресурсу", думать некогда, надо трясти. В тикет можно вписать story points, в том числе на дизайн, документацию и прочее. А потом эти story points в конце года просуммировать (что само по себе лютый бред), добавить LOC-и, почетные грамоты за внеурочные подвиги, все тщательно перемешать и получить для HR одну из трех искомых величин - below target, on target или above target. Да, так можно. Потом девелоперы пронюхают твои исчисляемые критерии и быстренько сориентируются, будут тебе и story points в полный рост, и миллион LOC-ов, и победить это тебе будет крайне непросто. Как побочный эффект толковые люди свалят, и очень быстро.

Насчет вопроса что бы девелопер хотел видеть от руководителя ответ простой. Спланируй работу, раздай задачи на очередной двухнедельный спринт и отвали. Будут вопросы - спрошу.

ППКС

[Komissar]

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

родственные души!

Я хочу чтобы мои программисты не выполняли тупо ТЗ а понимали для чего это будет сделано, видели систему более шире. Вся эта фигня баги, шмаги, ревью и т.д. в идеале должны отсутствовать.

вот-вот

[valchkou]

Насчет вопроса что бы девелопер хотел видеть от руководителя ответ простой. Спланируй работу, раздай задачи на очередной двухнедельный спринт и отвали. Будут вопросы - спрошу.

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

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