Лучший метод оценки производительности труда программиста? [закрыт]

#работа #производительность

Вариант 1. Количество строк кода в единицу времени. Плохой вариант. Все равно что
измерять готовность самолета по его массе. Не учитывает китайский стиль.
Вариант 2. Работает/не работает. Слишком примитивно, не учитывает оптимизацию. Бомбейская
школа программистов была здесь.
Вариант 3. Программист или его коллега сами оценивает работу друг друга исходя из
собственного опыта. Зависит от программиста. Не объективно, но может принести результат
или дело кончится холиваром.
Вариант 4. Оценка бесполезна для процесса и не стоит тратить на нее время.
Вариант 5. Быстрая микроценка проделанной за день работы. Не дает общей картины.
Кто каким образом делает это? Я использую вариант 5 + вариант 1 без учета копипаста,
китайского кода и с учетом комментариев, получается около 5-20 кБайт в день в зависимости
от части над которой идет работа. Какие еще есть варианты?    

Ответы

Ответ 1

Вариант 6. Ежедневные 5-минутные тесты/головоломки для программистов. Вроде заданий
из инструментальных тестов на навыки. Особенно с утра. 
Плюсы:

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

Минусы: 

где брать тесты, постоянно новые, интересные, адекватные работе и навыкам. Возможно,
тесты придётся покупать;
метрика оторвана от контекста работы.


Ответ 2

Хорошей общеизвестной метрики нет (и вряд ли может быть), но никто не мешает вам
установить локальную для себя метрику продуктивности. Вы же подсознательно знаете,
сделали вы сегодня больше, чем вчера, или меньше.
Метрика производительности такого рода имеет смысл только в контексте проекта, а
не разработчика. Рекомендую ознакомиться с информацией по поводу Теории Ограничений
и по поводу ее распространения на Agile процессы.
Фактически, вашим вариантом номер 5 вы частично переизобрели Daily Scrum Meeting.


Ответ 3

В нашей команде уже достаточно давно используется следующая схема: 

Команда разделена на группы по 3-4 человека, в каждой группе есть главный (обычно
более опытный сотрудник). Его задачи:   


раздача и контроль выполнения
заданий, он тесно связан с процессом
разработки (практически каждой задачи
в его группе), поэтому в курсе
прогресса   
review документации и кода    
оценка качества выполнения
задач и эффективности членов его
группы. Тесное взаимодействие людей
одной группы практически гарантирует
адекватные оценки со стороны лидера
группы.


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

т.е. наша схема склоняется к варианту 3


Ответ 4

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