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

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

Поэтому всегда есть, что исправлять.

Можно что-то усовершенствовать, добавить новый функционал. Исправлять функционал, который работает, покрыт тестами, делает клиентов довольными… не имеет смысла.

Но где пределы? Где предел максимальной эффективности и инструменты измерения?

Для этого существуют и давно применяются эстимейты, скрам, спринты и другие методологии.

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

Частично с вами согласен. В моем случае менеджером является собственник, у которого есть опыт работы разработчиком. Но это скорее исключение. По поводу управления программистами и взаимодействия с начальством (собственником) рекомендую послушать выступления Григория bobuk Бакунова из Яндекса.

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

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