Менеджер проекта ежемесячно рассылает статистику по часам работы, количеству исправлений ошибок, это типично?

В некоторых странах это может быть даже незаконным без одобрения профсоюзов, поэтому большое значение имеет то, где вы находитесь.

Но если оставить в стороне юридический аспект: это может привести к нежелательным последствиям:

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

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

Продуктивные разработчики совершают ошибки, плохие разработчики никогда их не совершали:

• «Двигайся быстро и ломай вещи» имеет более высокую верхнюю границу производительности и исследований. Вы быстрее продвинетесь в своей области и будете первыми на рынке других. Если вы боитесь что-то сломать, ваши продукты будут застаиваться.
• Экспериментальные новые функции не будут принадлежать кому-либо из-за боязни быть связанными с ошибками, возникающими в новой захватывающей области.
• Ваши разработчики учатся, совершая ошибки быстрее, чем каким-либо другим способом. Разработчик, который настолько осторожен, что не делает ошибок, не учится так же быстро, как тот, кто пытается, терпит неудачу и снова встает.
• По моему собственному опыту, если вашей конечной целью является высокофункциональное, очень надежное (но не идеальное) программное обеспечение, вы добьетесь этого намного медленнее, написав идеальный код с первого раза, чем быстрее напишете посредственный код и протестируете его. (Под «идеальной» надежностью я подразумеваю военные или аэрокосмические приложения — нельзя использовать память кучи, потому что распределитель может выйти из строя из-за надежности)
• Разработчики, занимающиеся рефакторингом всей кодовой базы, будут последними, кто коснется каждого фрагмента кода, в котором есть ошибка. Такое поведение будет наказываться, препятствуя просроченной работе по рефакторингу.

Да, плохое управление типично.

Основная философия, очевидная здесь, называется управлением «теорией X». Т.е. разработчики ленивы и по возможности не будут работать, поэтому за ними нужно следить очень четко и публично.

Я не говорю, что авторитарный подход с низким уровнем доверия никогда не работает ни в одной отрасли. Но, по крайней мере, в программном обеспечении нельзя запугивать и стыдить человека на пути к хорошим результатам. Это достаточно сложная сфера, и нужно, чтобы люди хотя бы немного заботились о ней. Так что если теоретики правы, а разработчики все ленивы, то это уже пиздец. И если разработчики на самом деле являются самомотивированными людьми, стремящимися помочь бизнесу в достижении его целей, открытое неуважительное отношение к ним — не лучший способ удержать их в таком состоянии.

Помимо теории X, что, если этому менеджеру удастся заставить разработчиков делать именно то, что их просят? Это все равно будет плохой исход. Метрики — это просто узкие измерения мира, и все они имеют неверные результаты. Их можно обыграть. Обычно люди проявляют добрую волю не делать этого в обмен на то, что их работу оценивают таким образом, что учитываются не только измерения. В данном случае цена за плохие номера — это публичный позор, поэтому я не думаю, что здесь есть какие-либо причины для доброй воли.

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

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

Как только вы опубликуете эти цифры, даже если руководство не будет активно вознаграждать/наказывать разработчиков на основе этих цифр, разработчики будут сравнивать себя с другими. Они попытаются зарекомендовать себя как тот, кто производит небольшое количество дефектов. Хотя это, вероятно, именно то, на что надеется премьер-министр, у него есть ряд нежелательных побочных эффектов, некоторые из которых уже упоминались в других ответах.

• Разработчики могут спорить, почему ошибка была вызвана не ими, а кем-то другим, кто коснулся другого фрагмента кода или предоставил им неполную информацию. Они могут быть даже правильными. Такого рода «игра с обвинением » может быстро отравить атмосферу не только внутри данной команды, но и между разными командами. В то время как межкомандное сотрудничество может фактически уменьшить количество ошибок, эта инициатива может иметь противоположный эффект, еще больше их разрознив.
• Это также может быть пустой тратой времени на обсуждение того, следует ли классифицировать сообщенный тикет как ошибку или запрос на изменение, когда все, чего хочет клиент, — это чтобы приложение работало так, как он запросил.
• Синдром «не мой код» . Вместо того, чтобы установить совместное владение кодом, это может привести к тому, что разработчики не захотят прикасаться к коду другого разработчика (например, помогать, когда коллега болен), как потому, что их могут в конечном итоге обвинить в уже существующих ошибках, так и потому, что они более скорее всего, внесет ошибки, чем их отсутствующий коллега.
• Скрытие дефектов . В большинстве случаев разработчик будет первым, кто заметит, что с его кодом что-то не так. Обычный процесс заключается в том, чтобы сообщить об ошибке, исправить ее, и QA проверит исправление. Если создание отчетов об ошибках наказывается, разработчик может предпочесть хранить молчание, пока они не найдут время, чтобы исправить это тайно. Это может задержать исправление ошибки. Хуже того, это означает, что никто не собирается проверять наличие непреднамеренных побочных эффектов рассматриваемого исправления ошибки.
• Разработчики как тестировщики с завышенными ценами . Разработчики заинтересованы в перепроверке каждого коммита. Это может быть не так уж плохо, но для низкоприоритетных проблем может быть более дорогостоящим, чем просто отчет QA об ошибках.

Есть поговорка, которую я выучил много лет назад:

If you work a lot, you make a lot of mistakes.
If you work less, you make fewer mistakes.
If you don't work at all, you make no mistakes. 
If you make no mistakes, you get promoted. 

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

Сокращая количество ошибок, я в основном выполняю работу QA, за исключением того, что передавать им код, полный ошибок, неэффективно. Это становится эффективным, когда количество ошибок настолько мало, что лучше передать QA, чем самому искать ошибки. Если я найду и исправлю все ошибки перед передачей, это на самом деле неэффективно, потому что они лучше находят ошибки. Теперь, если меня оценивают по количеству ошибок, которые я создаю, уравнение для меня меняется. Выполнение неэффективной работы дает лучший результат для меня. Так угадай, что я буду делать.

Есть много историй, когда QA и разработчики оценивались по «количеству найденных ошибок» и «количеству исправленных ошибок». Очевидно, что разработчик намеренно добавит ошибку, сообщит QA, где она находится, и когда QA обнаружит и сообщит об ошибке, исправит ее за две минуты. Выигрыш/выигрыш для двух сотрудников за счет компании.