Давайте представим, что вы поставили своим программистам KPI — количество ошибок. Первый вопрос, с которым вы столкнётесь — а что именно считать критической ошибкой? Достаточно ли десяти сообщений в Сентри или нужно что‑то более серьёзное, к примеру упавшая конверсия?

Допустим, вы решили эту проблему, и теперь все стороны понимают под словом «ошибка» одно и то же. Теперь давайте представим, как поменяется образ мыслей программиста, который оценивает свою работу по количеству ошибок.

Вот, к примеру, на проекте стоит очень старая версия Django, скажем 1.8. Это сильно замедляет разработку — сложно разворачивать окружение, нельзя подключать современные инструменты, трудно искать документацию. Обновить Django в принципе можно, и работа после этого пойдёт гораздо приятнее и быстрее. Но ошибок при смене версии не избежать, а за эти ошибки потом придётся отвечать — если и не вычтут из зарплаты, то как минимум посчитают.

Или есть у вас на проекте очень старый код, который достался в наследство от предыдущей команды, скажем управление правами доступа. Прилетает задача — добавить новую роль в эту систему. Вроде бы можно написать ещё парочку if, скорее всего ничего не сломается. А можно посидеть пару дней и сделать управляемую систему контроля доступа на основе ролей, с которой приятно будет работать. Как думаете, какое решение примет программист с KPI на количество ошибок? А будет ли он счастлив на работе, когда весь код в системе превратится в бесконечную череду вложенных if?

Мне кажется, команду разработки лучше строить из людей, которым не нужен KPI, чтобы делать свою работу хорошо. Чтобы просто подойти к коллегам и вместе придумать меры по исправлению проблем, не нужна никакая система мотивации. Скорее всего, их эти проблемы беспокоят не меньше вашего.