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

[valchkou]

По каким метрикам или критериям вы бы хотели чтобы работодатель/руководитель оценивал вашу эффективность как специалиста?
Интересуют именно объективные оценки, которые можно предъявить лицом.

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

[Vladimir Kr.]

есть такое мнение, что "bad acting is bad directing":

то что ты знаешь и умеешь, как программист - это одно,
как эффективно работаешь - это другое,
как тебя оценивают - это третье,

все три, как могут быть связаны с друг-другом, так и нет.

по существу вопроса: я бы хотел, чтобы оценивали по количеству critical issues (в проде).

[valchkou]

как тебя оценивают - это третье,

вопрос именно про это.
как бы ты хотел чтобы тебя оценивали, так чтобы оценка о тебе совпадала или даже была выше твоей личной.

по существу вопроса: я бы хотел, чтобы оценивали по количеству critical issues (в проде).

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

[vdfs]

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

Метрики самого кода - если такое есть на проекте. Как статистика sonar cube. Тестовое покрытие. Уязвимости и баги с точки зрения анализатора.

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

Добавить к этому, насколько активно человек делает код-ревью сам. Пропускает ли косяки. Насколько серьезные баги вылезают после его ревью.
Бездельники не делают код-ревью, или делают для галочки.

Статистика в JIRA может дать очень хороший вектор. Такая как число переоткрытий багов / задач. Сколько задач / сторипоинтов закрыто за единицу времени. И т.п.

[vdfs]

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

Тут к сожалению очень сложно конкурировать с бездельниками и жополизами. Давить на visiblity, постоянно светить перед начальством, насколько хорошо всё стало после внесенных изменений. Что-нибудь с цифрами, графиками и зеленым цветом.

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

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

[nyekimov]

Как бы я хотел чтобы оценивали меня:

1. Сложность заданий над которыми я работаю, и скорость выполнения. Всегда есть список задач, которые дашь не каждому. Особенно когда надо сделать побыстрей.
2. Количество багов в коде, написанного мной.
3. Количество багов, которые я решаю за кем то.
4. Смотреть на то, какое влияние я имею на коллег. Например сейчас очень часто приходится разжевывать коллегам их задачи. Так как я на фирме не первый день.
5. Больше к предыдущему пункту. Заметить, что я могу и делаю код ревью. Очень многие не могут, не умеют, бояться делать код ревью коллег. Просто апрув и все. И везде, где я работал, было ограниченный круг людей, кто мог подсказать что то действенное.
6. Замечать инициативных людей. К примеру я если вижу, что что-то можно автоматизировать, я это делаю, очень часто это требует интеграции с другими командами и я например не боюсь поднимать вопросы на эту тему. Но не всегда это замечают.
Также инициативность может касаться рабочего процесса, например учить людей писать юнит тесты, учить людей Новым Паттернам и так далее. Но это уже все из серии бонус на exceeds. И очень сильно зависит от компании. У нас хватает джунов и мидлов, которых надо растить. Бывает небольшие но крайне эффективные команды состоящие из сениоров, там супервижна надо будет минимум.

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

И да, очень важно понимать, кого мы оцениваем. Чем выше должность, тем больше играют роль софт скилы и соответсвенно критерии на годовом ревью.
У сениора обычно же в подчинении система и там важно показать, каких новых метрик добилась система. Особенно круто, если легко подсчитать денежную сторону - я внедрил в модуль технологию X и повысилась пропускная способность, что принесло компании Y денег.

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

Я хочу чтобы в мое ревью входила оценка кучи говна, которую нужно было разгрести чтобы сделать тот «несерьёзный» PR в одну строчку...

[nyekimov]

Я хочу чтобы в мое ревью входила оценка кучи говна, которую нужно было разгрести чтобы сделать тот «несерьёзный» PR в одну строчку...

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

[Komissar]

когда вокруг еще паслись мамонты, а я еще сам кодировал, у меня был неплохой начальник, из "старой гвардии" (когда в начальники вырастали из толковых инженеров, а не из пустобрехов МБА). Так вот он мне на эвалюациях говорил, что он очень ценит меня за то, что я:
1) быстро схватываю (не нужно много объяснять)
2) быстро делаю
3) не портачу (он называл это A-quality code)
4) "все продумываю" (thinking things through)

[Dweller]

Когда я был менеджером, мне не нравилось когда работники
1) не могли оценить сколько времени займёт сделать что то, при более менее детально поставленной задаче
2) имели дни когда совсем ничего не было сделано по существу
3) пытались делать много но совсем не то что от них требовалось
4) блокировались или блокировали других несвоевременным исполнением или просто утаиванием каких то фак-тов
Список можно продолжать бесконечно, но моя главная задача как IC высокого уровня на данный момент это облегчать жизнь своему менеджеру, тогда будешь в дамках ходить
Это значит просто поставить себя на его место, понять его требования и цели, и идти в такт, не создавая проблем.

[Komissar]

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

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

Я хочу чтобы в мое ревью входила оценка кучи говна, которую нужно было разгрести чтобы сделать тот «несерьёзный» PR в одну строчку...

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

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

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

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

«Иногда выгодно платить людям, чтобы они НЕ программировали вообще» (с)

[valchkou]

ну вот уже что то.
Уточню, да я менеджер, но продолжаю и программистом быть. Метрики мне нужны как самому, так и для оценки моих людей.
Некоторые метрики доступны
- код на гитхабе
- поинты в жире
- баги в продакшн
Чем моложе прог, тем больше кода он должен выдавать, для того чтобы быстрее научиться.
Качество ожидать на этом этапе сложно, если только как бонус, но рвение и усердие обязательно.
А вот деле сениор/принципал меня больше бы интересовала сложность решаемых задач, а не количество. Пока я с этим не экспериментировал.
Да мы используем фибоначи для оценки сложности тасков, но это больше на уровне ощущений спинного мозга. Каждая команда по своему.
Я подумываю ввести у себя уровень таска типа джун/мид/сениор/про.

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

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

как то так.

[M. Ridcully]

Боже-ж мой, свежеиспеченые белые обезьяны опять про метрики.
Может, строки кода посчитать?