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

[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]

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

[tessob]

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

Сложно представить. Нормальный руководитель, который принял на себя управление незнакомой командой, постарался бы избежать или перенести ревью на несколько месяцев. Делать выводы на основе KPI - это явное указание на то, что у человека нет опыта руководства. KPI за последние 3 десятка лет были опробованы во многих областях и доказали свою полную несостоятельность. Просто если вы их там у себя введете, то в результате получите ситуацию, когда девелоперы будут стараться брать только те таски, которые положительно влияют на KPI. В результате KPI будет неуклонно расти, а качество кода, производительность, стабильность стремительно снижаться. Девелоперы, которым "не похер" будут пытаться исправлять ситуацию, но ценой худших KPI, что в конечном итоге приведет к их выгоранию и переходу в другую компанию или проект.

Все наемные работники делятся на две группы - те кому "похер", и те кому по какой-то причине "не похер". Чего-то путевого можно добиться только со второй группой. Если первых не получится перевести во вторую группу, то максимум, что можно будет сделать – это оставить все как есть. Так что иногда надо “девок менять, а не кровати двигать” или KPI/феншуй вводить.

[Vladimir Kr.]

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

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

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

баги вообще - да, могут быть. PR, комиты, тикеты - они просто должны быть, но не надо считать строки кода.
фиксишь за другими? молодец! главное чтобы новая бага от этого не появилась.
не дошли до прода? ну возьми букварь по атжалу, там четко написано - над сториком работает команда, кому тикеты записывать будем?

[nyekimov]

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

Вывод хороший. Номер 2 сильно попахивает микроменеджментом. Бывают такие задачи, в которые надо долго въезжать, если мы говорим о каком то куске мамонта в который надо что то новое добавить. Я могу работать 10 часов, потому что погружение в детали занимает только два часа. А могу как все, с 10 до 5 и ровно в 5 встал и пошёл, только так из-за отрыва от контекста задача будет сделана хорошо если за 8 дней, вместо 3 дней по 10 часов. Потом естественно если озвучили срок в 2 недели, рассчитывая, как это принято в оджайле, на самого слабого человека в команде, то почему я не имею права один день ничего не делать?

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

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

Это традиционная игра «назови ETA» меня всегда забавляет - чтобы сделать фичу А, надо сначала пофиксить баг Х. Чтобы пофиксить Х, нужно разобраться с А и В. Чтобы разобраться с А и В... А потом выясняется что вкалывал ты не в ту сторону, или целый день ничего по существу не сделал

[nyekimov]

Это традиционная игра «назови ETA» меня всегда забавляет - чтобы сделать фичу А, надо сначала пофиксить баг Х. Чтобы пофиксить Х, нужно разобраться с А и В. Чтобы разобраться с А и В... А потом выясняется что вкалывал ты не в ту сторону, или целый день ничего по существу не сделал

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

[Dweller]

Это традиционная игра «назови ETA» меня всегда забавляет - чтобы сделать фичу А, надо сначала пофиксить баг Х. Чтобы пофиксить Х, нужно разобраться с А и В. Чтобы разобраться с А и В... А потом выясняется что вкалывал ты не в ту сторону, или целый день ничего по существу не сделал

Если выдаётся что то типа
День 1) разбирался с А
День 2) разбирался с Б
И т д
То через какое то время начинаешь задумываться не только о том в правильную ли сторону копает товарищ, а копает ли в принципе или сидит весь день привете

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

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

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

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

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

Это традиционная игра «назови ETA» меня всегда забавляет - чтобы сделать фичу А, надо сначала пофиксить баг Х. Чтобы пофиксить Х, нужно разобраться с А и В. Чтобы разобраться с А и В... А потом выясняется что вкалывал ты не в ту сторону, или целый день ничего по существу не сделал

Если выдаётся что то типа
День 1) разбирался с А
День 2) разбирался с Б
И т д
То через какое то время начинаешь задумываться не только о том в правильную ли сторону копает товарищ, а копает ли в принципе или сидит весь день привете

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

был у меня такой потенциальный кандидат в мои будущие менеджеры Даже скипу на меня жаловался.....

[Dweller]

Это традиционная игра «назови ETA» меня всегда забавляет - чтобы сделать фичу А, надо сначала пофиксить баг Х. Чтобы пофиксить Х, нужно разобраться с А и В. Чтобы разобраться с А и В... А потом выясняется что вкалывал ты не в ту сторону, или целый день ничего по существу не сделал

Если выдаётся что то типа
День 1) разбирался с А
День 2) разбирался с Б
И т д
То через какое то время начинаешь задумываться не только о том в правильную ли сторону копает товарищ, а копает ли в принципе или сидит весь день привете

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

был у меня такой потенциальный кандидат в мои будущие менеджеры Даже скипу на меня жаловался.....

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

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

Это традиционная игра «назови ETA» меня всегда забавляет - чтобы сделать фичу А, надо сначала пофиксить баг Х. Чтобы пофиксить Х, нужно разобраться с А и В. Чтобы разобраться с А и В... А потом выясняется что вкалывал ты не в ту сторону, или целый день ничего по существу не сделал

Если выдаётся что то типа
День 1) разбирался с А
День 2) разбирался с Б
И т д
То через какое то время начинаешь задумываться не только о том в правильную ли сторону копает товарищ, а копает ли в принципе или сидит весь день привете

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

был у меня такой потенциальный кандидат в мои будущие менеджеры Даже скипу на меня жаловался.....

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

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

[Dweller]

Это традиционная игра «назови ETA» меня всегда забавляет - чтобы сделать фичу А, надо сначала пофиксить баг Х. Чтобы пофиксить Х, нужно разобраться с А и В. Чтобы разобраться с А и В... А потом выясняется что вкалывал ты не в ту сторону, или целый день ничего по существу не сделал

Если выдаётся что то типа
День 1) разбирался с А
День 2) разбирался с Б
И т д
То через какое то время начинаешь задумываться не только о том в правильную ли сторону копает товарищ, а копает ли в принципе или сидит весь день привете

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

был у меня такой потенциальный кандидат в мои будущие менеджеры Даже скипу на меня жаловался.....

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

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

Понятно. Ну что ж, уровень менеджера должен соответствовать подчиненных