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

[nyekimov]

Бюджет то не резиновый. Я ещё изначально хотел спросить, ради чего вся игра? Во всех местах, где я работал, основная оценка была по сложности задач, и приоритету задач, кто делает самые стратегически важные задачи для руководства, тот любимчик и будет иметь больше бабла. Оно не резиновое. Везде есть нормативы по типу - 1 из 5 может получить exceeds, очень хорошо, если два . Ну и если остальным перепадёт что т более менее приятное, то очень хорошая компания.

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

Там же кроме самих метрик ещё куча всего играет роль, например один мощный чувак у нас имеет свои жизненные проблемы. Дочь у него требует особого внимание и он работает с 7 до 3 часов дня. За это время он выдаёт кучу всего для архитектуры. А обычные таски он делать не может, так как у большинство разрабов и проект менеджеров из кали время после 3 часов дня cdt все ещё продуктивно, особенно для дискуссий. В метрики такой случай не ляжет, но если вы дадите ему свободу в раб графике - он алмаз.
И также по многому остальному.

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

[blanko27]

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

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

[mikeG]

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

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

Если оценивать по багам, будут улучшать статистику багов.

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

[xrundel]

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

[Komissar]

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

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

Если оценивать по багам, будут улучшать статистику багов.

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

был в свое время такой комикс у Скотта Адамса в середине 90х, где объявили bug bounty - платили денежное вознаграждение за найденные баги, и программисты в сговоре с QA стали специально создавать новые баги, и делить вознаграждение. "I'm going to write myself a minivan" - была такая фраза оттуда.

[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 строк или подправленная одна. Сделал это джун или принципал тоже на прибыль/убытки не влияет