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

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

[...] уровень менеджера должен соответствовать подчиненных

Я тут вас полностью поддерживаю!
(хоть меня и не покидает ощущение, что вы это поняли также как и пример с А и Б )

[Dweller]

[...] уровень менеджера должен соответствовать подчиненных

Я тут вас полностью поддерживаю!
(хоть меня и не покидает ощущение, что вы это поняли также как и пример с А и Б )

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

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

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

[Inchik]

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

[Komissar]

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

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

[valchkou]

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

У нас нет QA почти, все тестируется программистами и соответственно автоматизируется по макс, юнит тесты, автотесты.
Все что прог сморжил в основной бранч уже через день в продакшн!
У нас почти нет консалтеров, потому что консалтеры не отвечают за производимый ими код. А это важно в нашем продукте.
Весь менеджмент у нас технический, вырос из программистов, начиная от CEO, CTO заканчивая такими как я.
Именно поэтому, друзья, я и спросил вашего авторитетного мнения.
Я сам такой же программист ка и вы и прошел все стадии, начиная от никто в ташкенте и москве и до менеджера тут.
Я прекрасно осознаю что такое локи или баги или поинты. Я не мба выпускник и продолжаю сам контибутить и в гитхаб и в стаковерфло.
Не стесняйтесь своих детских комплексов, выскажите все что вы хотите тут и сейчас.
И возможно, уже скоро, не без моей помощи, это может превратиться в мейнстрим

[Komissar]

начиная от никто в ташкенте и москве и до менеджера тут.

вы с таким придыханием говорите "менеджер", забывая, что как раз манагеров в омерике как собак нерезанных, а талантливых программистов - единицы.

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

Автор, как программист, вы должны быть знакомы с Explore & Exploit алгоритмом. Это идеальное решение в вашей текущей ситуации свежеиспеченного менеджера. Ну и забудьте свои мечты о совмещении менеджерские и программирования, вы можете делать (хорошо) только одно. И как правило менеджерская часть вытесняет все остальное

[xrundel]

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

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

Оценивать нужно комплексно - начиная от LOC и заканчивая интуицией. Нет никакой универсальной формулы - всё зависит от проекта, от компании, от ваших полномочий, от команды. Бывает что оценивать не нужно совсем - скажем брeинсторминг, R&D. Бывает что LOC самое оно - особенно когда проект активно пишется с нуля. Бывает когда оценить нужно вообще написанную документацию а не сам код.


После работы с сотнями пограммистов у меня появился набор правил которые работают и набор правил которые не работают. Например, я точно знаю что LOC это неплохой дополнительный индикатор работы. Точно знаю что не нельзя работать с оффиса 3 дня и дома 2 дня. Точно знаю что хорошие пограмисты проявляют себя в первые 2 недели - дольше не имеет смысла принюхиватся. И т.д.

Со временем у вас появится свой набор многократно проверенных правил - мой лист для вас не подойдет.

[xrundel]

начиная от никто в ташкенте и москве и до менеджера тут.

вы с таким придыханием говорите "менеджер", забывая, что как раз манагеров в омерике как собак нерезанных, а талантливых программистов - единицы.

Это так. Но на 10 талантливых пограмистов будет 1 талантливый менеджер который способен направить работу этих пограмистов в продуктивную сторону. Так что хорошие пограмисты это золото - но хороший менеджер это бриллиант.

[xrundel]

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

Ну конечно. Какой смысл писать код если у вас есть умение поиска и организации людей которые умеют писать код лучше вас.

[xrundel]

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

Лол. Это невозможно. Невозможно просить программиста оценить бизнес составляющую его труда - откуда он это знает? Задача оценки это и есть задача бизнеса. Например

A: "Цена ошибки огромная. Задача - сделать фичу что бы подключить большого клиента так что бы ничего не сломалось". Т.е. качественно, надёжно, дорого

B "Есть интересная гипотеза. Задача - как можно скорее проверить фичу - или она кому-то нужна вообще". Т.е. быстро и дешево

C: "Есть план разработки где фича должна быть запущена до Х. Потому что начинается маркетинг, потому что скоординирована работа многих людей" . Т.е. главное что бы было прогнозируемо.

Эти 3 разные задачи требуют 3-х разных методик оценок и конечно трансфер этого знания в команду.

[Komissar]

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

Vaulchkau придется похоронить себя как программиста, я его сразу предупредил.

[valchkou]

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

Vaulchkau придется похоронить себя как программиста, я его сразу предупредил.

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

[Komissar]

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

Vaulchkau придется похоронить себя как программиста, я его сразу предупредил.

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

директор это тот же манагер. Только управляет не IC, а другими манагерами. Вместо 2х проблем (начальство и подчиненные) тебе придется иметь дело с 3мя: начальство, подчиненные и подчиненные подчиненных.

Если тебе сладкой кажется з/п манагера, значит, тебе мало платили в IC.

[BronenosezPotemkin]

Самое хорошее, что менеджер может сделать - это поменьше парить мозги всякими оценками эффективности. Считать строчки кода, серьёзно? У вас там, наверное, не программисты в подчинении, а секретари-машинистки.

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

Если тебе сладкой кажется з/п манагера, значит, тебе мало платили в IC.

+1
У менеджера первого звена ТС на равне с Sr IC, а местами даже меньше

[blanko27]

Теоритически, любая метрика качества бизнес процесса, после того как люди начинают ее оптимизировать, перестает работать (Goodhart's law: Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes. Corollary: all metrics of scientific evaluation are bound to be abused). Поэтому выбирайте те, которые больше нравятся вам, это, в принципе, все равно.

[valchkou]

директор это тот же манагер. Только управляет не IC, а другими манагерами. Вместо 2х проблем (начальство и подчиненные) тебе придется иметь дело с 3мя: начальство, подчиненные и подчиненные подчиненных.
Если тебе сладкой кажется з/п манагера, значит, тебе мало платили в IC.

какая разница сколько каких проблем, как будто у инженера их меньше. Главное тут ограничить их по времени, с 9 до 5.
это всего лишь вопрос оптимизации самого ограниченного ресурса. Как получить больше за единицу отработанного времени.
Ну а тем более, у нас менеджер это фактически тоже программист, поэтому кодить на уровне средненького сериора я еще не скоро разучусь.
Не получится водить руками, вернусь к плану Б или В.

[valchkou]

Теоритически, любая метрика качества бизнес процесса, после того как люди начинают ее оптимизировать, перестает работать (Goodhart's law: Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes. Corollary: all metrics of scientific evaluation are bound to be abused). Поэтому выбирайте те, которые больше нравятся вам, это, в принципе, все равно.

был у меня один интересный момент, пришел ко мне постград, даю ему фактически первый таск закодить.
нужно перегнать данные из одного формата в другой, c кучей всяких if/else/case/catch. Я расписал входные/выходные параметры.
Вот приходит PR на ревью. Боюсь даже смотреть по опыту прошлых выпускников.
Гляжу в его код, а там .... красота! Все понятно, четко и структурно и тесты покрыты полностью.
Как оценить работу? Понятно что не по локам, и не по сложности. А приятно посмотреть и ревью я ему дал отличный.

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

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

[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" - была такая фраза оттуда.