Оценивать нужно качество работы - качество кладки кирпича, качество уборки снега, качество продаж.
Автор статьи на хабре - намекает, на проблему некомпетентности начальства, которое не может оценить качество работы программиста.
Это не значит, что его нельзя оценить, это значит что начальство тупоголовое, которое занимает не свое место.
Команду/разработчика/ит- можно оценивать с разных позиций - качество софта (кол-во багов, производительность), качество кода (исключение дублирования кода, оптимизация), качество инфраструктуры (выбор серверов, выбор софта, выбор механизма работы).
Все зависит от целей этой оценки.
Для премирования, можно выработать коэффициенты основываясь на кол-ве багов/времени их исправления, кол-во выполнения заявок по доработке и развитию системы/трудозатраты.
При частой модификации системы заметно, не вооруженным глазом, как некоторые "умные товарищи" натыкаются на свои же говнокод, долго разбираются, порождают новые баги и т.д.
Есть даже пример, когда пару человек просто зависли в багтрекере, чинили одну функцию, ломали другую и т.д.. Некоторые же умудрялись, не исправлять касяки, а исправлять только последствия, и так работая "в ручном" режиме - для таких бы премиальный коэффициент стремился бы к нулю.